go/build: Module support is disabled when ReleaseTags don't match the default. #46856
Labels
modules
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env
)?go env
OutputProblem description
go/build
implements module support by calling out to thego list
command, which is very nice. Unfortunately, this functionality is disabled ifbuild.Context
hasReleaseTags
different from the default build context (determined by the version of Go that built the binary). I assume this restriction comes from the fact that you can't passReleaseTags
to thego list
command.Unfortunately, this check is not particularly helpful because there's no guarantee that the
go
tool in PATH will match the version the program was built. A typical example would be a tool that is distributed as a pre-built binary.In addition, when a
go/build
user tries to match release tags to the GOROOT they are working with, module support may silently turn off, which is a surprising and tricky to debug behavior.Possible solution
A better version of that condition could be checking that
go version
matchesReleaseTags
, and let the library user to addGOROOT/bin
toPATH
if they require so, or maybe even use thego list
from GOROOT by default.In addition, it's worth considering whether a silent fallback is appropriate in case of
ReleaseTags
specifically. I can see that the fallback allows us to maintain compatibility with earlier behavior, which did not depend on thego
tool or its version. But maybe disabling the fallback whenGO111MODULE=on
is set would be reasonable?A side note on
x/tools/go/packages
go/packages
sidesteps this problem by not allowing the user to setReleaseTags
to begin with. #41231 suggests the user to manipulate PATH to achieve the desired effect.Foressing a suggestion to use the
go/packages
instead ofgo/build
, it is unfortunately difficult in my case for two reasons:go/build
, updating it is a lot of work.go/packages
doesn't seem to expose any information about embedded files, butgo/build
does.The text was updated successfully, but these errors were encountered: