Support for non-versioned dependencies?

[puerco]

I just noticed that the requirements.txt extractor silently ignores all Python packages listed in requirements.txt without a version.

I see in the tests that this is intentional. We have some use cases where returning the package list without versions (and also producing unversioned purls) would be useful. Could this be a configurable behavior?

I'm happy to submit a patch to support this in Python, I just wanted to check if you'd consider it.

[puerco]

Mmh it looks like < and > are also not supported. I'm assuming that osv-scalibr will only return dependencies when it can compute an actual version?

[oliverchang]

@erikvarga @another-rex thoughts?

We have plans to support full dependency resolution for requirements.txt next year via deps.dev resolvers. This will give the most accurate results that we can just basing off an unlocked requirements.txt. CC @cuixq who can probably add more detail here!

[cuixq]

I think it makes sense to have two extractors here (also what we do for Maven):

• one requiring network access which invokes deps.dev resolver for full dependency graph resolution
• another one can be run offline with best effort to extract dependencies

[another-rex]

I think we definitely should parse packages in requirements.txt without versions

I believe we had a similar discussion during the initial migration of osv-scanner extractors to osv-scalibr. For vulnerability scanning, not having a version is not very useful (except in cases of malicious packages and unfixed vulns), but for SBOM generation even packages without a version should be accounted for.

[erikvarga]

Yes, it should be fine to report packages that don't have any versions associated (or where we currently don't support version resolution, e.g. < and >). Feel free to send a PR for this.

[evankanderson]

Is there a standard format for Inventory objects which represents a half-open version range, or a partial range of versions? Right now, Version is a string, which leaves open many opportunities for representation.

Additionally, the attached Extractor has a ToPURL method -- it sounds like the PURL version-range definition is well-defined but new.