Skip to content
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

Closed
DeedleFake opened this issue Nov 30, 2023 · 6 comments
Closed

Comments

@DeedleFake
Copy link

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.

@gopherbot gopherbot added this to the Proposal milestone Nov 30, 2023
@seankhliao
Copy link
Member

this would essentially be the same as gonew from #61669

@DeedleFake
Copy link
Author

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
Copy link
Member

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
Copy link
Author

DeedleFake commented Dec 1, 2023

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: gonew: templates for new modules #61669 (comment)
  • 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
Copy link
Member

point 2:

Perhaps eventually it will graduate to 'go new'.

@DeedleFake
Copy link
Author

Well alright then.

@golang golang locked and limited conversation to collaborators Nov 30, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants