Definitions for `DiscoveredPackage` and `DiscoverdDependency` are very different

[Hritik14]

Minor nitpick:
DiscoveredPackage used uuid field
https://github.com/nexB/scancode.io/blob/5f2cbae33c1ac7fa843fb4bddf9ab3f62fc831b2/scanpipe/models.py#L2534-L2536

DiscoveredDependency uses a CharField
https://github.com/nexB/scancode.io/blob/5f2cbae33c1ac7fa843fb4bddf9ab3f62fc831b2/scanpipe/models.py#L2837-L2840

---

We need to discuss the distinction between a Package and a Dependency.

1. When is a dependency not a package ?
2. All all packages dependency of the project being scanned currently
3. CycloneDX schema's dependencies are only a mapping from a component to a component, should we opt for a similar approach ?

[tdruez]

DiscoveredPackage and DiscoverdDependency model schemas are inherited from ScanCode-toolkit models.
https://github.com/nexB/scancode-toolkit/blob/develop/src/packagedcode/models.py#L387

[Hritik14]

Is there a reason that Package and a Dependency are different citizens in SCTK ? A package can be dep. of another package and vice versa.

[tdruez]

@pombredanne @AyanSinhaMahapatra ^

[pombredanne]

Is there a reason that Package and a Dependency are different citizens in SCTK ? A package can be dep. of another package and vice versa.

So there are a lot of small and important semantic differences that we are likely handling poorly at this stage... and here some general considerations.

1. We treat a package as a concrete thing, that must be present as concrete code in a given codebase.
2. We treat a dependency as a possible, potential thing, that is not present in a codebase.

Here a dependency is either:

• pinned with a set version.
• defined by a range constraint (or some other arbitrarily complex expression). Some are rather simple like the minimal version used in Go.
• resolved to a concrete version.

When resolved or pinned, it may become an actual package.

[Hritik14]

1. We treat a package as a concrete thing, that must be present as concrete code in a given codebase.

In a certain codebase My Project, if the requirements.txt file looks like the following:

requests==2.0.0
vulnerablecode>=30.0.0

Which of these would be treated like a package ? Before the code is built (ie venv created and deps fetched), nothing is concrete except the codebase being scanned.

1. We treat a package as a concrete thing
2. We treat a dependency as a possible, potential thing

IMO, it would help to define this thing as a package and then deriving 1 and 2 as metadata of being present in the codebase or not. The current structure does not support specifying parent-child relationships between packages which might be present in the codebase (consider a vendored codebase where dependency upto two levels are present).

defined by a range constraint (or some other arbitrarily complex expression). Some are rather simple like the minimal version used in Go.

Does it help to store ranges in an SBOM ? Shouldn't an SBOM be data about a precise snapshot of the codebase at a point of time which will always resolve to a single version ?
Further, does cyclonedx or other standards support providing a version range as one of its elements ?

[Hritik14]

Do have a look at the above PR for the proposed changes in the current schema to support transitives. It is heavily WIP and needs many changes but conveys the concept

[Hritik14]

Related: aboutcode-org/scancode-toolkit#2418