-
Notifications
You must be signed in to change notification settings - Fork 17.6k
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
cmd/go: allow -getmode=vendor in environment variable #26585
Comments
To date we have never provided an environment variable that duplicates a command-line flag in the go command. I'm reluctant to start now. |
Even though I work in a large organisation, my team is the only one that uses go. We are unable to set up extra infrastructure (metadata servers, proxies) because of manpower required to maintain it is not available. The
I am expecting modules to support this workflow without developers having to jump through hoops every time. Setting environment variable which can be overridden from command line is one option. Other option is to specify the default getmode in In day-to-day operations, I want devs to be able to just execute |
Change https://golang.org/cl/126656 mentions this issue: |
What version of Go are you using (
go version
)?go1.11beta2
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?darwin/amd64
Feature request
Can we please have an environment variable which would enable the relevant vgo operations to always use -getmode=vendor (or any other value)? Something like GOMODULE_GETMODE?
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.
This issue is generated from a unaddressed comment made on a closed issue.
The text was updated successfully, but these errors were encountered: