Update 2024-08-21 by matloob: The proposal has been updated to the following:
The proposal is to allow package@version arguments to go build.
They would behave similarly to how they do for go run: the module containing package at the given version would be loaded outside of the context of the current module. It would use cmd/go/internal/load.PackagsAndErrorsOutsideModule, so it would load the given module as if it were a requirement of an otherwise empty module. This also enforces that the version of the module the package belongs to doesn't have replace or exclude directives.
Similar to go run, if mulitple packages are supplied, they would be required to belong to the same module at the same version. (Though providing multiple package@version arguments wouldn't be useful in practice because the main use case would be to produce the build outputs.)
Alternative: allow to change the installed main package name in go install command
Since go1.16, go install accepts arguments with version suffixes. go install places the output in $GOPATH/bin or $GOBIN, but does not allow the output binary's name change.
When a user wants to use multiple versions of tools, the user need to be careful not to overwrite other versions.
Different versions may be coming from different module paths.
e.g. VS Code Go extension uses two different versions of gocode (stamblerre/gocode and mdempsky/gocode). In order to install the former, it does switching GOBIN to use a temporary directory, installing it, and renaming and copying it to the real GOBIN.
Alternative: There are other proposals for applying the same to go run (#42088) and go list(#44203). Extending go build in the same way (or extending go install) will help simplifying the tool installation workflow.
cc @jayconrod @bcmills @matloob
Update 2024-08-21 by matloob: The proposal has been updated to the following:
The proposal is to allow
package@versionarguments togo build.They would behave similarly to how they do for
go run: the module containingpackageat the given version would be loaded outside of the context of the current module. It would use cmd/go/internal/load.PackagsAndErrorsOutsideModule, so it would load the given module as if it were a requirement of an otherwise empty module. This also enforces that the version of the module the package belongs to doesn't have replace or exclude directives.Similar to
go run, if mulitple packages are supplied, they would be required to belong to the same module at the same version. (Though providing multiplepackage@versionarguments wouldn't be useful in practice because the main use case would be to produce the build outputs.)Alternative:allow to change the installed main package name ingo installcommandSince go1.16,
go installaccepts arguments with version suffixes.go installplaces the output in$GOPATH/binor$GOBIN, but does not allow the output binary's name change.When a user wants to use multiple versions of tools, the user need to be careful not to overwrite other versions.
Different versions may be coming from different module paths.
e.g. VS Code Go extension uses two different versions of
gocode(stamblerre/gocode and mdempsky/gocode). In order to install the former, it does switchingGOBINto use a temporary directory, installing it, and renaming and copying it to the realGOBIN.Alternative: There are other proposals for applying the same to
go run(#42088) andgo list(#44203). Extendinggo buildin the same way (or extendinggo install) will help simplifying the tool installation workflow.cc @jayconrod @bcmills @matloob