proposal: cmd/go: allow "go install" a forked repository with cmd

[mitar]

So if there is a CLI tool implemented in Go (e.g., github.com/example/tool/cmd/tool) which I fork into my namespace and slightly fix (e.g., github.com/mitar/tool/cmd/tool), there seems to be no way to currently do go install github.com/mitar/tool/cmd/tool@latest to get my fork installed locally without doing find/replace over all files to change original package name to my fork's.

I would propose that there is such a way, maybe by providing a replace directive using CLI argument while installing, e.g.:

go install -replace gogithub.com/example/tool=github.com/mitar/tool@main github.com/example/tool/cmd/tool@latest

This is to support a common use case of collaboration in open source projects:

• I fork the project.
• I make a fix.
• I make a PR to the main project.
• While the main project is reviewing my PR I want to use the fixed CLI tool, e.g., in the Dockerfile which originally had go install with the original project.
• After PR is merged, I start using go install from original location again.

Currently I have to do the PR and then in another branch make one more commit on top of the PR, doing find/replace to replace module paths in all the codebase. This is tedious and error prone if during the review of PR I am asked to do modifications. Then I have to do the fix and then re-do the module paths replacements in a new commit.

[snan]

While the main project is reviewing my PR I want to use the fixed CLI tool

Not only that. How do we even build our modified version to test it before sending a pull request?

go build places the binaries in the local dir but go install doesn't place them in the $GOPATH.

[dionysius]

Just stumbled on this. But this is really a weird situation for handling forks with go install as the wished outcome depends on the type of fork. If you do a hard-fork, I'd assume that you replace the import directive on the whole project and you're done. But you don't want to do that with soft-forks. What if someone just "mirrors" the project and wants to use that mirror? This issue basically represents: you can't go install soft-forks and mirrors. And i think is also difficult to define where a good place is to define such replace directive:

• If a form of replace is added to go install, everything and everyone needs to use it. You taint the soft-fork with changes in the self-contained CI instructions if they use such command and you don't want this to merge to the original
• If a form of replace is added to go.mod (assuming support for it), you taint the soft-fork with those changes you don't want to merge to the original. But finally everyone could simply go install this soft-fork without extra arguments.

And you definitely want 0 changes on mirrors.

The question also goes a little bit further (if you want to apply it): What if you want to go install an original project but you want to replace a dependant module (e.g. security update) to a more recent one (The project doesn't get updates right now for some reason). What would be appropriate here? So what I'm trying to say is that this question could also be applied to dependant modules.

[snan]

Both methods need to be available.

• If a form of replace is added to go install, everything and everyone needs to use it. You taint the soft-fork with changes in the self-contained CI instructions if they use such command and you don't want this to merge to the original

In the README file (which can be out of band if you don't wanna mess with the repo docs). Perfect for soft forks or for my use case (I'll send patches but I wanna use my souped-up version

A. To test before I send the patches,
B. To use while I'm waiting for upstream to accept,
C. To keep using in case upstream rejects.

• If a form of replace is added to go.mod (assuming support for it), you taint the soft-fork with those changes you don't want to merge to the original. But finally everyone could simply go install this soft-fork without extra arguments.

That is a hard fork. And it needs to be possible to make hard forks too.

Here's a blog post summarizing my understanding of the situation.

[gedw99]

i would also like this :)

The proposed way seems pretty decent to me...

go install -replace .....

[i4ki]

@seankhliao pointed out that #60452 is a duplicate of this issue.
I understand that the root cause is the same, but the proposal here does not apply in my case.

The project https://github.com/mineiros-io/terramate was moved to its own GitHub organization and now resides at https://github.com/terramate-io/terramate. The go.mod module declaration was updated and newer releases can be installed using the new module path.

Because of the GitHub HTTP redirect for transferred projects, all the API requests to https://github.com/mineiros-io/terramate repository are redirected to https://github.com/terramate-io/terramate, then go install still works if using the old module path with old releases, but new releases require the new module path...
In this case, the -replace flag proposed here does not make sense, as this is the same project that was just moved to a different location.

In other words, Terramate < 0.3.0 requires go install github.com/mineiros-io/terramate/cmd/terramate else go install github.com/terramate-io/terramate/cmd/terramate.

As mineiros-io/terramate automatically redirects to terramate-io/terramate can't this be enough to consider them the same? And then make go install work if using both module names?

[i4ki]

Additionally, the Go proxy returns all releases created for mineiros-io/terramate when asking for the releases of terramate-io/terramate, and vice-versa, see below:

https://proxy.golang.org/github.com/mineiros-io/terramate/@v/list
https://proxy.golang.org/github.com/terramate-io/terramate/@v/list

Only the v0.3.0 release was created with the module github.com/terramate-io/terramate but the proxy lists all versions (because of the HTTP redirect). So essentially, they are the same module?

[win5do]

This is really needed, otherwise you'll have to replace the module name in all go file to customize a small function.

Many libraries heavily reference internal packages and cannot be modified externally.

PR to upstream is sometimes long and difficult.