Open mfechner opened 3 years ago
Hi Matthias,
Unfortunately I don't think this can be generally fixed for Gitlab hosted packages.
modules2tuple tries to figure out an (account, project, optional_submodule_path)
tuple by splitting a package name like gitlab.com/gitlab-org/security-products/analyzers/semgrep
. It can be done unambiguously for Github hosted packages because Github doesn't allow slashes in project names, but in Gutlab case it's unclear where project name ends and submodule name starts.
I'm afraid modules2tuple won't be of much help for this port. Also, the recently added GO_MODULE [1] might work better for situations like this because it uses go for figuring out and downloading dependencies.
[1] https://docs.freebsd.org/en/books/porters-handbook/special/#using-go
Hi Dmitri,
ok I understand. Maybe modules2tuples and the ports should not try to download the packages/sources from github and/or gitlab but from pkg.go.dev
.
I have another problem with one go module: https://pkg.go.dev/gopkg.in/DataDog/dd-trace-go.v1@v1.31.0
I reported this issue already here: https://github.com/DataDog/dd-trace-go/issues/929 Problem is here that the tag is existing on pkg.go.dev but not on github which causes an unavailability for FreeBSD.
Do you think we should redesign here the way go packages are downloaded a switch from github/gitlab to pkg.go.dev (if this is even possible)?
This was the reason GO_MODULE was added. Quoting [1]
The specific case of loading packages should still be done by invoking the go command, which remains the single point of truth for package loading algorithms.
modules2tuple is still supported and will be supported as long as it works, but only go command knows all the details of how to resolve versions and download packages.
Hi,
I just tried to create a new port for semgrep: https://gitlab.fechner.net/mfechner/Gitlab/-/commit/a0268faf641510cabb4d223c525e51559138501b
The port is far from being complete, but as next step I need now to generate the GH and GL tuples to make the required go modules available for the build process.
If I execute
make gomod-vendor
I get:If I build it manually with
go build
I get:So it seems that modules2tuples can maybe not handle the deeper nested dependency?
Any idea how to get this fixed?
Thanks a lot.