Idiomdrottning’s homepage

go install a fork

Golang has become pretty rough on installing forks. I ran into the same frustrations as these peeps.

It only affects forks of packages that uses go’s module system, so there’s no problem for mdna.

But if you have a fork of a go package that does use modules, you’ll run into this error when you go install it:

module declares its path as: path/to/their/repo
        but was required as: path/to/your/repo

This is a serious obstacle for open source collaboration so it’s pretty imperative that go lang fixes the issue. It’s a bug in go install as far as I’m concerned.

Meanwhile, you have two bad compromised options:

Keep only their version canonical

Maintain two branches, once where you’ve renamed the paths and one where you haven’t. The rename should be in a single commit that you keep rebasing on top.

Let’s say you’re hacking on main. Don’t rename the paths in main.

Then create a new branch from main, I’m gonna call it hyperlocal, and make a single commit that has all the path renames. And for many project, doing the module path renames can be a hairy thing that touches many lines of code, which is why this is such a flaw in golang’s module system.

Then you can go install from the path to your forked repo but add @hyperlocal to the end of the path so go knows that that’s the branch you’re using.

Then do

git checkout main

if you want to hack more or if you want to pull changes from upstream. And everytime you’ve done that,

git checkout hyperlocal
git rebase main

That moves your path rename commit on top of the stuff in main. Then if you have a remote with hyperlocal, you’ve got to force push to it.

This is bad because it’s a ton of work for you, the contributor, and it’s also bad since you are force-pushing to the branch that has the renamed paths so other people can’t interact normally with that branch.

Talk about hoop city.

Sayonara upstream

Obviously if you’re taking over maintainership completely, there’s no problem. Just rename the paths and your version is the official one from now on. The easiest solution, but it’s not collaborative in spirit. It’s going to be fiddly for upstream to use your changes. If you at least kept your path renames in one separate commit, upstream can do some Magit juggling to keep up but it’s gonna be a chore for them.

Conclusion

I’m staring daggers at the go install and go module design team.