Consider adding GO15VENDOREXPERIMENT support
kardianos opened this issue · 9 comments
In 1.5 the go command will read the environment variable GO15VENDOREXPERIMENT. If enabled, it will use the local "/vendor/" folder for dependencies. This replaces the need to manage GOPATH variables as dependencies can be fetched directly into the vendor folder and resolved there when built. This allows the GOPATH to not be modified. The contents of the vendor folder can be ignored.
Will you consider supporting this approach?
Good question, I don't know, I'd have to have more information, I'm googling for it but can't find a clear specification of it, do you happen to have one?
To be honest I don't see changing the GOPATH as a problem, quite the opposite, it's a very inexpensive way to avoid the world of trouble involved in sharing dependencies across projects without any significant downsides, I'm a big fan.
What do you think would be involved in supporting this new workflow? How likely is this experiment to stick around and become a part of the standard workflow in Go? I would certainly need to know a lot more than I do right now in order to consider it properly, I am skeptical of the proposed solutions to vendoring/versioning from the Go team, but I'm not opposed to thinking it through and consider whether it'd make sense to support it.
The CL for it is here: https://go-review.googlesource.com/#/c/10923/ and https://go-review.googlesource.com/#/c/10922 .
The note from rsc is here: https://groups.google.com/d/msg/golang-dev/74zjMON9glU/4lWCRDCRZg0J (slight change, not a flag but a env var).
I understand you may not see changing GOPATH to be a problem. However when building code on other services (CI, heroku, AppEngine, etc) they need to know how to build code. The vendor directory is a standard way to provide this. Feel free to only enable this when you see the flag for now, but I would highly encourage you to adopt it for the sake of the larger go community.
I think the key question here is: what does this allow that isn't possible already?
Building in environments like CI, Heroku, etc is perfectly possible today, as is requiring packages from a vendor directory, this only requires you to set a value in an env variable (GOPATH), the proposal is to set another value in another env variable (GO15VENDOREXPERIMENT) for a less flexible way to solve the same problem, if I understand correctly.
Am I missing anything?
I think the key question here is: what does this allow that isn't possible already?
Nothing.
But it plays nice with a single GOPATH. This is nice for developers. And more importantly, it takes many approaches people have been using and give a standard "blessed" approach.
What specific use case is blocked by the way gpm is currently implemented though? If you're using GO15VENDOREXPERIMENT to keep vendored packages in /vendor/ then it wouldn't make sense to also add that same package to Godeps and have their version changed, correct? It'd be defeating the purpose of vendoring it in the first place.
This new approach pushed by google (vendoring) can be used interchangeably with gpm's approach (manifest file revision locking), but there seems to be little to gain from mixing both of them instead of choosing one or the other.
As far as I can see there is no use case that isn't covered by the current implementation, unless that assertion is incorrect there is no reason to add code.
You don't have to check in the code found in "vendor". However by checking
out code into the vendor folder you preserve the developers GOPATH.
On Mon, Jun 29, 2015 at 11:14 AM Pablo Astigarraga notifications@github.com
wrote:
What specific use case is blocked by the way gpm is currently implemented
though? If you're using GO15VENDOREXPERIMENT to keep vendored packages in
/vendor/ then it wouldn't make sense to also add that same package to
Godeps and have their version changed, correct? It'd be defeating the
purpose of vendoring it in the first place.This new approach pushed by google (vendoring) can be used interchangeably
with gpm's approach (manifest file revision locking), but there seems to be
little to gain from mixing both of them instead of choosing one or the
other.As far as I can see there is no use case that isn't covered by the current
implementation, unless that assertion is incorrect there is no reason to
add code.—
Reply to this email directly or view it on GitHub
#79 (comment).
gpm uses go get in order to fetch the code, it puts it wherever the go tool thinks is appropriate. Are you saying I should modify that?
Because gpm changes the revision of the repository after "go get", I would
recommend yes, you should modify that. Or at least copy the fetched package
into the vendor folder before changing to a specific version.
On Mon, Jun 29, 2015 at 11:44 AM Pablo Astigarraga notifications@github.com
wrote:
gpm uses go get in order to fetch the code, it puts it wherever the go
tool thinks is appropriate. Are you saying I should modify that?—
Reply to this email directly or view it on GitHub
#79 (comment).
This experimental new feature tries to solve the same problem as gpm with a different approach, vendoring means that a manifest file and revision locking are redundant, so it wouldn't make sense for gpm to add code to tackle a use case that doesn't exist for gpm users.
Be that as it may, I thank you for bringing that feature to my attention and making me think about the whole thing, that is a contribution on itself!