IssueRaiser

proposal: cmd/go: allow versioned `go build` commands

**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 `G

Posted by hyangah on Feb 20, 2021, 11:00 PM

Tags

Related issues

Raise real-world problems, find people facing the same issue, and discuss solutions.3,000 issues0 comments

onboarding (E-commerce)

proposal: cmd/go: allow versioned `go build` commands

hyangahFeb 20, 2021, 11:00 PM

**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 `G

Comments (0)

No comments yet. Start the discussion.

Comment on this issue