Align package types with purl-spec?

[georgevanburgh]

Something that was mentioned as part of #26 was the possibility of adding a package-url to the output. This could follow the purl-spec, which would allow downstream consumers to use other tools that conform to the spec to download new versions of packages for analysis. However, some of the package type names used in this project conflict with the well-known purl types from the spec. Here's how things compare currently:

purl-spec	package-feeds	match?
cargo	crates	❌
composer	packagist	❌
golang	goproxy	❌
gem	rubygem	❌
nuget	nuget	✔
npm	npm	✔
pypi	pypi	✔

In general I think this boils down to the purl-spec project naming according to the package type, whereas we have feeds named after the package source. In terms of options, I see a few:

• Update package-feed feeds to match the purl-spec types. This would be a one-time breaking change for existing downstream consumers.
• Keep the package-feed naming for the type field that we already publish, and add an additional type mapping to be used when constructing a package-url. This would be more confusing, but would not be a breaking change for consumers.
• Not worry about conforming with purl-spec at all. This would make it harder to build interoperable tooling.
• Something else?

It might also be worth thinking about whether we want to maintain a feed per source, or per package type. If we want to end up in a place where feeds have configurable URLs, and the ability to pull from multiple different sources - naming feeds after the package type rather than the source might make more sense.

[georgevanburgh]

There may be some relevant points to this discussion in package-url/purl-spec#33

[tom--pollard]

Whilst I don't feel that the schema should necessarily provide a constructed purl field, there's obviously merit in providing the means for downstream subscribers to do so with the metadata that is provided to them.

Inherently at this stage with only one known public 'subscriber' (this being https://github.com/ossf/package-analysis/tree/main/scheduler) it wouldn't be to disruptive to propose a breaking change to the type field to match the purl-spec types. In the case of package-analysis the change to the rubygem type would cause an issue, all be it a minor fix. A breaking change could also be suggested much inline with your second point, but providing both the package source & package type as two explicitly named fields instead of the obviously somewhat ambiguously named type. If we were to propose a breaking change (2.0?) then that'd be my current vote.

In terms of the last point about URL configurability and how that reflects in the name of the feeds packages themselves, this usecase came up when @Qinusty was implementing the original configuration surface:

#74 (comment)

[pombredanne]

It would be awesome to reuse the same types as purl.

[pombredanne]

The reason why is frictionless interop with many tools and DBs that use purl today. This includes the OSSF OSV and Google OSV and large number of open source SCA tools. Otherwise you condemn every downstream user to re-implement mappings (disclosure: I created purl ;) )