In the interest of not having everyone invent their own keys to add to ExperimentalMetadataInfo, I'm opening this issue to request a few more standardized fields for the PackageInfo provider.
Additional fields I would like to see are fields which are either commonly provided by package managers and potentially useful when generating reports in some contexts, or are required for some SBOM-like APIs, e.g. GitHub's dependency submission API. I don't much care to bike-shed the names of these fields as long as there's a place to put this information.
homepage: The project's home page. This is often available for rust crates, npm packages, PyPi or conda packages, and so on, and is often helpful to a reviewer asking the question "what is this dependency for?"
manifest: The manifest file (e.g. requirements.txt, go.mod, Cargo.lock) that declares this dependency. Used by the GitHub dependency submission API, and useful for "we need to update this dependency, which file do I need to edit?"
ecosystem (definitely open to suggestions for a better name here): which package manager this package came from, e.g. debian, maven, conda, pypi, cargo, npm. Helpful for interpreting the package name (e.g. "is this numpy the python package or is this the rust crate?" Convenient for report-generating rules that want to sort things, but arguably redundant with first component of the purl (after the scheme).
In the interest of not having everyone invent their own keys to add to
ExperimentalMetadataInfo
, I'm opening this issue to request a few more standardized fields for thePackageInfo
provider.Current fields, for reference: https://github.com/bazelbuild/rules_license/blob/5b980eaa19dec16c85d8ec5e58c16257c8738ea3/rules/providers.bzl#L55-L58
Additional fields I would like to see are fields which are either commonly provided by package managers and potentially useful when generating reports in some contexts, or are required for some SBOM-like APIs, e.g. GitHub's dependency submission API. I don't much care to bike-shed the names of these fields as long as there's a place to put this information.
requirements.txt
,go.mod
,Cargo.lock
) that declares this dependency. Used by the GitHub dependency submission API, and useful for "we need to update this dependency, which file do I need to edit?"debian
,maven
,conda
,pypi
,cargo
,npm
. Helpful for interpreting the package name (e.g. "is thisnumpy
the python package or is this the rust crate?" Convenient for report-generating rules that want to sort things, but arguably redundant with first component of thepurl
(after the scheme).