So I’ve created a fork of a Go module (cobra), written some new code and tests. Then in my client app, I attempted to use my new fork and because of my naive approach, there were all sorts of errors and issues. I realised that forking a Go project is a little more complicated than I thought (I’ve only been using Go for a few weeks so I’m still learning).
So I need to know how to do 2 things
First what do you have to do in the fork, to make sure that clients can use it correctly.
What changes to make in client projects to switch over to my forked version of cobra.
Googling around doesn’t give me the whole story, that covers both of the points above.
I have been able to run tests in my fork with my changes, but I havent pushed those changes yet. I realise I have already made a mistake here, because I have not changed the local module path. IE, the path in my go.mod file still points to the orginal (github.com/spf13/cobra) instead of my fork github.com/snivilised/cobra, but this doesn’t break running the tests locally. I also havent changed any import paths in the forked source code.
Experimenting by making adhoc changes to paths, doesnt seem to work. I guess I need to do some kind of
“go mod edit -replace”, but I thought this was only a temporary measure that shouldnot be checked in, so I’m totally confused and need somebody who knows about this to let me know what the correct workflow is.
These are exactly what you need to do for #2, in addition to making client code changes for whatever API changes you made. For temporary testing you might add a replace directive in your go.mod to point to your fork.
Hi @mje, thanks for your reply. I found a few articles to work from, because this isnt as simple as you might think it is. The first issue I have is with the fork itself. Because I want to submit a pull request, I can’t simply change the import paths in the fork, because they will be the wrong paths for the pull request. There is something I need to do here that will be pull request friendly and at the same time imports from the fork path instead of the original path. What this is, is currently a mystery.
I do understand what you mean for the client, replacing the import paths to the fork. This part is intuitive and I guess this is where I would use a replace directive to modify the path of the fork module, but what on earth do I do to the fork!
If I understand correctly, you can probably leave the imports as they are in the code and add replaces in your fork’s go.mod file, but don’t commit the modified go.mod file in the PR.
ok, thanks @mje, so it just means that I have to remember to revert the mod replace in the fork before the PR. That seems to make sense, cheers, I will experiment and report back.