cmd/go: document how to disable a vendor folder (particularly important for Go1.7+)

[laher]

1. What version of Go are you using (go version)?

go1.7rc3

1. What operating system and processor architecture are you using (go env)?

darwin amd64

1. What did you do?

Having vendored a package in the vendor folder, I cannot temporarily ignore that folder and use the GOPATH (VCS'ed) copy of the package, while testing/integrating changes to that repository.

Note my company's use case:

• Most of our projects import packages from one private shared repository, and additionally several 3rd party repositories. The problem relates to changes we make in our own shared repository (golibs).
• We would like to be able to use a kind of 'novendor' mode whilst refining and integrating changes in this shared golibs repository.
• In Go1.5 and Go1.6, we can acheive this by setting GO15VENDOREXPERIMENT=0 during development / testing of changes to the shared repo. This is a pretty fundamental part of our workflow. In Go1.7, this facility is going away.

1. What did you expect to see?

Either:

• a commandline flag for the go toolchain to disable use of the vendor folder, something like, go [build|install|test] -novendor

Or:

• a recommendation to temporarily rename the vendor folder.
• Something like "rename vendor directory to _novendor. See proposal: cmd/go: do not enable GO15VENDOREXPIRIMENT by default until Go 1.7 #13218 for rsc's suggestion along these lines.
• NOTE: Also include a recommendation for ignoring (e.g. .gitignore) the _novendor folder, and a local-ignore for the vendor folder (e.g. .git/info/exclude or git update-index --skip-worktree).

Or, some other solution. I can't come up with any other workable alternative. I have tried and failed to devise alternatives using symbolic links, git submodules, and partially vendoring dependencies. None of these have resulted in satisfactory outcomes. Note that I have as-yet been unable to find a 3rd party 'vendoring' tool which addresses this issue, either.

1. What did you see instead?

The Go1.7 release candidates do not provide any flag for switching off vendoring, nor do they document alternatives, nor provide recommendations for this use case.

Thankyou

[rhedile]

We are in need of a similar solution. We are operating under Compliance constraints and are having problems with our Auditor's "Audit Trails". "Vendoring" introduces "Import" by path length and thus "conditional dependancy" which we can't get them to accept at the moment. We currently relocate "Vendored" code and rewrite the import statements. At the moment this trivial. However, pressure is growing to enforce "no vendored code".
njv

[kostya-sh]

@laher

IMHO -novendor flag doesn't provide very consistent user experience. Other than go tool there are other tools that rely on vendor behavior such as gocode (autocompletion) and goimports. They normally are executed by an IDE/editor in the background and mechanism to change their arguments on per project basis doesn't always exist.

Additionally if golibs in your example has some private vendored dependecies -novendor flag simply won't work. And BTW the standard library in Go 1.7 has vendored dependencies in GOROOT. So some packages (e.g. net/http) from the stanrdard library cannot be built without vendoring support.

Finally with many packages in vendor folder and many projects with different versions of vendored dependencies it is almost impossible to ensure that GOPATH has the correct versions when vendoring is disabled.

For experiments you can rename vendor to _vendor or just hack in vendor/golibs and move the changes manually to the golibs project later.

@rhedile

Would "no vendor directories in the source control" rule will satisfy the compiance? It is probably easier to enforce than making sure that build scripts turn off vendoring support.

[quentinmit]

We'll discuss this again, but FYI, we are likely to decide to maintain the status quo (no ability to disable vendoring). The word "EXPERIMENT" in the environment variable was meant to convey that the existence of the environment variable was temporary.

[cespare]

As @laher suggested, we should add a recommendation (in the release notes?) to rename 'vendor' directories if vendoring behavior isn't desired.

[laher]

Thanks for all the info. It's clear to me now. @kostya-sh: "the standard library in Go 1.7 has vendored dependencies in GOROOT" - this is key.

So, could you please treat this as a request for documentation? I suggest here: https://golang.org/cmd/go/#hdr-Vendor_Directories

In Go 1.5, as an experiment, setting the environment variable GO15VENDOREXPERIMENT=1 enabled these features. As of Go 1.6 they are on by default. To turn them off, set GO15VENDOREXPERIMENT=0. In Go 1.7, the environment variable will stop having any effect.

An extra sentence or 2 would suffice. Could it be as follows please, including a recommended name (to encourage consistency in 3rd party tooling)?

To temporarily disable a vendor folder, simply rename it. It is recommended to use a standard name such as _novendor, and to ignore it from your SCM

Thanks again. Note: renaming issue to reflect this comment.

[laher]

For reference, I've taken the advice I received here, and made a shell script to help support my workflow.

https://github.com/laher/vendoff

It mainly just does a mv vendor _novendor and a git --skip-worktree. It also does the reverse to revert back to normal. See README.md for instructions and rationale.

[quentinmit]

We're happy to take clarification for the documentation, but I do not want to do anything that prescribes a particular style of usage for the vendor directory.

[bcmills]

In module mode, only the vendored dependencies of the main module are used for the build.

So now we have an answer: to disable vendoring, set GO111MODULE=on and ensure that the main module does not have a vendor directory.