-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: cmd/go: add flag to go get
to download module into directory
#64483
Comments
this would essentially be the same as |
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. |
The first example:
|
In that case it is indeed similar, but it's missing
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. |
point 2:
|
Well alright then. |
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 fromgo 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 ofreplace
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, togo get
orgo 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 thatgo install
wouldn't work for anyways.The text was updated successfully, but these errors were encountered: