Repository navigation
Align output with ScanCode format #24
Description
In current JSON output, the top package has further packages and dependencies. Dependencies have further nested dependencies. Packages in packages is not the SCTK way, neither are deps in deps, nor packages in deps. We should adopt and eventually revamp the way to report dependencies in SCTK
Activity
pombredanne commentedon Mar 17, 2023
For backgrounders here are some notes wrt the different dependency contexts we face
Contexts:
With a MANIFEST: 1. package manifest: setup.py, csproj
we collect only first level direct dependencies
With a LOCKFILE: 2. lock file: requirements.txt with pinned versions
we collect flat or nested data structure where all deps are present with pinned versions
for example NuGet: project-assets.json
With an inspector RESOLUTION 3. dependency resolution: inspectors
The input is a list of direct dependencies from 1. (or from a lock file in 2.)
The output is a tree or flat list of deps
Today we handle:
A. A flat list of dependencies for a package if found in 1. MANIFEST
B. A flat list of dependencies not for a package if found only in a 2. LOCKFILE (say a solo requirements.txt) even Though some LOCKFILE are nested
C. We optionally track the "resolved_package" metadata in a dependency
Return a top level dependencies list in JSON