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

Closed
bradleypeabody opened this issue Jun 4, 2018 · 2 comments

Comments

@bradleypeabody
Copy link

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

@kardianos

This comment has been minimized.

Copy link
Contributor

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.)

@bradleypeabody

This comment has been minimized.

Copy link
Author

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 https://github.com/rsc/quote ./tmp-editing-quote

And make my go.mod file like this:

module github.com/bradleypeabody/hello
replace rsc.io/quote v1.5.2 => ./tmp-editing-quote
require rsc.io/quote 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.
Projects
None yet
3 participants
You can’t perform that action at this time.