💾 Archived View for idiomdrottning.org › go-install-forks captured on 2024-05-10 at 11:29:54. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
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.
mdna — a branch of Molly Brown
Meanwhile, you have two bad compromised options:
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.
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.
I’m staring daggers at the go install and go module design team.