Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
x/vgo: ability to modify and use version control on dependencies #25726
I realize I'm a bit late for #24301 but I wanted to mention/ask about preserving the ability to make (usually small) edits to modules that your code depends on and be able to commit these easily back to the repository. I believe this is still possible with what is currently planned (since it will, for now, still use git or svn or whatever) but as mentioned in the various conversations moving away from using specific version control commands - that would also remove this ability.
Use case: You are developing a large application A for a client and while doing it you encounter a problem that needs a module M to solve that specific problem. It's not specific to the client, it's a general problem and you want to make an open source library for it (presumably on GitHub). You make a rough version of module M and put it on GitHub as a v0/prerelease. Module M passes its own tests, a minimal set made in order to get started. You incorporate into application A, and two weeks later it crashes due to an a-bit-harder-than-usual-to-catch bug, e.g. double-locking a mutex, unchecked map writes, or even issues outside of Go's control like remote file system locking/race condition issues - or some condition you don't understand yet, all you know is "I used this in production and it crashed". In order to solve this problem, you might need to spend a good amount of time trying changes to module M to find and resolve the issue. Editing and testing module M in its own project by itself may not be feasible because the bug does not reproduce with simple test cases - only when invoked from application A. In this case, having to do a commit and push for every single change you want to check for module M would be unduly onerous. (There is also an expediency argument in favor of being able to do small changes to M while working on A, but the case where you literally can't test without running A is more important.) While I realize this isn't the most common case, I've run into enough that I think it's worth looking at.
One possible solution would be to preserve an option in whatever command(s) are fetching modules to fallback to the VCS-specific commands as opposed to using some other VCS-agnostic protocol - and preserve that functionality as a supported way of doing things if the developer still wants it.
Edit: It would also solve this issue to just have some kind of assurance that if I go into $GOPATH/src/path/to/project and replace what is there with a
@bradleypeabody I suspect this can already be done as you describe it.
If you have a dependency
Thanks @kardianos - I tried this and you're absolutely right, it works as described. I then went back and saw that while the vgo-module doc doesn't seem to describe this feature, it's actually covered really well in the tour.
Use the vgo tour hello example, I can then do:
And make my go.mod file like this:
Local edits in ./tmp-editing-quote are seen.
I think it's awesome and very useful for certain situations as described earlier. I'll go ahead and close, you guys already have this covered.