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

@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.

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.

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

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.

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.

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.

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.