Skip to content

x/vgo: allow vendor at top level of build #25073

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

Closed
rsc opened this issue Apr 25, 2018 · 3 comments
Closed

x/vgo: allow vendor at top level of build #25073

rsc opened this issue Apr 25, 2018 · 3 comments
Milestone

Comments

@rsc
Copy link
Contributor

rsc commented Apr 25, 2018

We've agreed to preserve vendoring at the root of the top-level module in a build but we haven't worked out the details. That's this issue.

@akavel
Copy link
Contributor

akavel commented Apr 25, 2018

Related use-case/experience report: #24088

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/118316 mentions this issue: cmd/go/internal/vgo: add -getmode=local, -getmode=vendor build flag

@kostix
Copy link

kostix commented Jun 13, 2018

@rsc can we please have an environment variable—akin to that venerable GO15VENDOREXPERIMENT—which would enable the relevant vgo operations to always use -getmode=vendor (or whatever it will end up named)?

The reason is that while $enterprise borderline caching proxies are a good thing—in theory, in practice we here at $dayjob are not yet ready to deploy something like this and are already using vendoring as an almost perfect solution to combat both the different variants of the "left-pad problem" (including the "github is down" one) and the versioning problem—everyone get the set of vendored packages of blessed versions, and the vendored packages get upgraded by explicit manual intervention after much discussion and experimentation and tests.
We'd like this to be working as easy as it is now in perpetuity, if possible.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants