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

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

Comments

Projects
None yet
4 participants
@rsc
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

This comment has been minimized.

Contributor

akavel commented Apr 25, 2018

Related use-case/experience report: #24088

@gopherbot

This comment has been minimized.

gopherbot commented Jun 12, 2018

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

@kostix

This comment has been minimized.

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 join this conversation on GitHub. Already have an account? Sign in to comment