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

x/vgo: ability to modify and use version control on dependencies #25726

bradleypeabody opened this issue Jun 4, 2018 · 2 comments

x/vgo: ability to modify and use version control on dependencies #25726

bradleypeabody opened this issue Jun 4, 2018 · 2 comments


Copy link

@bradleypeabody bradleypeabody commented Jun 4, 2018

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 git clone that invocations of Go tools will not clobber my local changes (or at least not without asking me or requiring a -f flag or similar).

@ianlancetaylor ianlancetaylor changed the title Versioned Go - ability to modify and use version control on dependencies x/vgo: ability to modify and use version control on dependencies Jun 5, 2018
@gopherbot gopherbot added this to the vgo milestone Jun 5, 2018

This comment has been minimized.

Copy link

@kardianos kardianos commented Jun 5, 2018

@bradleypeabody I suspect this can already be done as you describe it.

If you have a dependency msgh with a bug you can only reproduce in your context, create a new folder in the root of your module: called vendor-mod/msgh and clone the msgh repo at requried revision into that folder. Then use the replace directive in the go.mod file to point to that sub-folder. (If this doesn't work as a sub-folder today, it should work in a sibling directory outside the module project.)


This comment has been minimized.

Copy link

@bradleypeabody bradleypeabody commented Jun 5, 2018

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: git clone ./tmp-editing-quote

And make my go.mod file like this:

replace v1.5.2 => ./tmp-editing-quote
require v1.5.2

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.

@golang golang locked and limited conversation to collaborators Jun 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.