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: allow vendor at top level of build #25073

rsc opened this issue Apr 25, 2018 · 3 comments


Copy link

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.


This comment has been minimized.

Copy link

commented Apr 25, 2018

Related use-case/experience report: #24088


This comment has been minimized.

Copy link

commented Jun 12, 2018

Change mentions this issue: cmd/go/internal/vgo: add -getmode=local, -getmode=vendor build flag


This comment has been minimized.

Copy link

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.
None yet
4 participants
You can’t perform that action at this time.