proposal: cmd/go: add flag to `go get` to download module into directory

[DeedleFake]

Proposal Details

I just ran into the replace directive problem today. Again. Unfortunately, I see that #44840 has been locked without any reason given.

I have a project using github.com/diamondburned/gotk4-adwaita. The bindings use code generation. I forked it and regenerated to update to Libadwaita 1.4, but I can't use my own code without changing the module name in my fork. Changing the module name in my fork means that it is no longer compatible with upstream and there's zero chance of getting the changes merged upstream. The only way around that is to maintain two branches in my fork, once with the original module name and one with it changed. And in some other cases, such as ones where the fork is of something that itself is a dependency of something else used by the project, that wouldn't even work.

I was under the impression when Go modules were introduced that the replace directive was supposed to be the solution for this, but ever since support for them was dropped from go install <module>@<version>, there's been no good way to fix the problem that I know of. At this point, I'm not even sure what the point of replace directives is since they can't be used for their most likely use case.

The most commonly suggested workaround for this problem from an end user's point of view is to manually clone a module's repo and then to run go install directly in the repo. That's an option, but figuring out how to do so can be annoying, especially for an end user who just wants to install my project.

My suggestion, therefore, is to add a flag, maybe -into=<path> or something, to go get or go install that downloads the module at the requested version in the way it normally would, but then puts it in a subdirectory of the current directory instead of in $GOPATH/pkg/mod. That won't solve the problem of missing module version info, but it would at least simplify the usage of the module, as well as helping with modules that have more complicated build processes that go install wouldn't work for anyways.

[seankhliao]

this would essentially be the same as gonew from #61669

[DeedleFake]

I'm not sure that it is. That's for creating a brand new module from a template. This proposal just wants a simpler way to get an existing module, possibly from GOPROXY, at a specific version so that it can be built manually, not edited.

[seankhliao]

The first example:

$ gonew book.com/mybook-examples

(In this form there's no changing the module path, just clone and drop in a new directory for editing.)

[DeedleFake]

In that case it is indeed similar, but it's missing two one features:

• The ability to get the module at a specific version. That could probably be easily added, though, and makes sense for gonew's feature set from what I can see anyways. Never mind: https://github.com/golang/go/discussions/61669#discussioncomment-6599994
• Being built in to the standard Go toolchain. Requiring the installation of a separate tool in order to work around the go tool's odd refusal to respect replace directives is an extra, if fairly minor, inconvenience for the end user. It also precludes the option of having go install give an error message that explains how to clone the module manually when it sees a replace directive.

Edit: Looks like it already has one of them, though it's not in the initial post, and the second, while it would be nice, is less important. I guess it already covers it. Neat.

[seankhliao]

point 2:

Perhaps eventually it will graduate to 'go new'.

[DeedleFake]

Well alright then.