Add support for go packages in manifest files #148
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds support for go packages in manifest files.
Go uses multiple styles to reference packages/modules and their versions:
Packages
A package is a directory with a bunch of go files, and is further declared in the code of this package itself with "package foo" directives.
We cannot infer a PURL from a package only: we are missing the version and we do not know where the path or name of the modules ends.
Modules
A module is a collection of packages with a go.mod file at the root.
C) in go.mod we have "module nameminimum version" as in https://github.com/moby/moby/blob/6c10086976d07d4746e03dcfd188972a2f07e1c9/vendor.mod#L125 . This requires parsing the mod file as done elsewhere, like in the ScanCode toolkit.
D) in go.sum we have with an extra checksum as in https://github.com/moby/moby/blob/6c10086976d07d4746e03dcfd188972a2f07e1c9/vendor.sum . This requires parsing the sum file as done elsewhere, like in the ScanCode toolkit.
E) when running the
go
command line we can rungo get github.com/foo/foo-package@31c913b
to fetch a specific version of a module/package in the workspace. The version after the @ sign is the go module version, and the name before is the module/package path (github.com/foo/foo-package). We cannot infer the module unless we query the go proxy.Modules can have a PURL and have a version (at least we know either the pinned or minimum version from the mod or sum file).
A) and E) are not in scope here, because we cannot reliably infer a module from a package short of doing extra calls. This is best done elsewhere, for instance in fetchcode.
B) and C) are in scope and the input is that of a go.mod for now. Dealing with checksums is something different that should be handled elsewhere possibly in Scancode like in https://github.com/nexB/scancode-toolkit/blob/66d71661f5ede54cb0f3b36d7663c92a67030299/src/packagedcode/go_mod.py#L206