[gentoo-dev] rfc: go 1.13 and go modules

[William Hubbs <williamh@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1790 bytes --]

All,

First off, everything I'm saying here is definitely open to discussion;
they are issues I have found with go 1.13.

with Go 1.13, go modules are the default way to build software written
in Go. If upstream has a go.mod file in their distribution, this
version of Go will assume that they are using modules unless modules are
disabled explicitly by setting the GO111MODULE environment variable to
off[1], so if your upstream does not have go.mod, it will work as
before.

This is not turned off globally because upstream is encouraging projects
to move to using modules [3] [4].

So far, here is what I've found if an upstream uses go modules.

dev-vcs/hub vendors the modules into their upstream repository using
"go mod vendor" and keeps go.mod and go.sum up to date. The build commands in
their makefiles use the "-mod vendor" switch as well. In this case,
the ebuild author doesn't have to do anything about the modules.

If the modules are not vendored (there is no vendor directory in the
upstream repository), the only option I've tried so far is to run "go
mod vendor" in the root of the upstream repository then tar up the
vendor directory and mirror it on our infrastructure. In that scenario,
you need to add "-mod vendor" to any "go build" commands upstream uses
and have a src_prepare function that moves the vendor directory into the
appropriate place. See www-apps/trickster (not trickster-bin). This also
seems to avoid the module mirror database.

There is another option I want to try which is adding "go mod vendor" to
src_unpack for go packages.

Thoughts?

Thanks,

William

[1] https://golang.org/cmd/go/#hdr-Module_support
[2] https://golang.org/doc/go1.13#modules
[3] https://blog.golang.org/migrating-to-go-modules
[4] https://blog.golang.org/using-go-modules

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]