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: allow "go install" a forked repository with cmd #50278

Open
mitar opened this issue Dec 20, 2021 · 10 comments
Open

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

mitar opened this issue Dec 20, 2021 · 10 comments

Comments

@mitar
Copy link
Contributor

mitar commented Dec 20, 2021

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.

@Antonboom

This comment was marked as spam.

@snan
Copy link

snan commented Mar 11, 2023

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

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

snan commented Mar 31, 2023

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

gedw99 commented May 3, 2023

i would also like this :)

The proposed way seems pretty decent to me...

go install -replace .....

@i4ki
Copy link

i4ki commented May 29, 2023

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

i4ki commented May 29, 2023

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?

nockty added a commit to DataDog/vtprotobuf that referenced this issue Aug 8, 2023
This will make `go install` work.

See: golang/go#50278.
@acrazing

This comment was marked as duplicate.

@win5do
Copy link

win5do commented Nov 13, 2023

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.

@oxeye-daniel

This comment was marked as duplicate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Incoming
Development

No branches or pull requests

10 participants