I believe we should turn vendor on by default as planned in Go 1.6. Prolonging the time in which there are two modes of operation only increases pain and makes it that much harder for people to actively adopt the feature. Anyone who doesn't want "vendor" semantics has a very simple recourse: rename any directory named "vendor" to something else. All of us working at tip have been using the new vendor semantics for the whole Go 1.6 cycle and they seem to be working fine.

I don't see the lack of consensus that you do. I see that you disagree, but overall the vast majority of people seem happy with the new "vendor" semantics.

/cc @bradfitz @davecheney @kardianos @adg @kr for thoughts.

The main complaint with the vendor folder I've heard is that it isn't a workspace solution like wgo or gb.

That aside, without the vendor folder people will do one of:

a. alter GOPATH
b. alter the import statements
c. alter the packages in GOPATH

This is proven with years of history. Option (a) is equivalent to the vendor folder that is a single level (no sub-vendoring). Option (b) is equivalent to vendor folder without the rewrites. Option (c) requires a unique GOPATH per project and the a step to workspaces.

Historically when you ran "go get" on a package that used (a) it didn't break because you weren't compiling the package as the author intended. Historically (b) has the same issue that you bring up as the vendor folder. Lastly, both of these were done in often incompatible methods making creating tools hard and made forming developer expectations difficult.

The vendor folder will fix a huge number of issues seen in the wild of medium to large repositories. Support for it can't come soon enough.

If this causes a build issue, file a local or upstream bug. The vendor folder doesn't introduce this issue, it just makes it more visible. In other words, it makes it easy to vendor stuff in a standard way. This is really good.

Aside from the individuals I've met who want workspaces, most people I've met are excited about the vendor folder. The largest issue I've encountered isn't technical, it is education. Most people aren't aware of the concepts and different tools available to them. I believe the issue you present is an issue, but one resolved through education; I don't see a technical workaround. Every example that has been given that I've seen is manufactured in some way or another. Yes, I will happen. But it will be a bug and it can be resolved.

@rsc, I actually agree with how the vendor mechanism works, and am planning on trying to move it into the go/build package so that external tools can utilize it. However, the thread above shows a case where "deep vendoring" breaks a build. I believe you said in the thread that this behavior should not exist.

What I'm describing is the following structure:

local/project
    vendor/foo/bar/a
    vendor/fizz/buzz/b
        vendor/foo/bar/a

A test project shows that given foo imports both a and b, and turn b imports its own vendored version of a, the build breaks.

Perhaps my suggestion for pushing back the default (1.6) milestone is a bit hasty. But at the least I am suggesting that this case of "deep vendoring" be addressed before removing the GO15VENDOREXPIRIMENT variable (as of now, slated for Go 1.7)

EDIT: my concern is not having the ability to turn vendoring OFF in this situation, as described in Go 1.7

Re opt-out: Anyone can turn vendoring off by renaming the directory they have named "vendor" that doesn't mean "vendor, as described in the vendoring proposal" to any other string. Renaming will work for this purpose forever, certainly beyond Go 1.7. That is what we want people to do. We do not want people to change the environment variable depending on what code base they work on. It's bad enough that people have to do this for the Go 1.5 release. The goal is to get people moved over to the new meaning (and again that might mean some people renaming some directories to avoid the new meaning) and back to a state where everyone's tools behave the same way.

Re build breakage, I will reply again on the thread about that. I want to keep that conversation off this issue. It's not a bug.

On Thu, Nov 12, 2015 at 3:46 PM, Kyle Wolfe notifications@github.com
wrote:

What I'm describing is the following structure:

local/foo
vendor/foo/bar/a
vendor/fizz/buzz/b
vendor/foo/bar/a

A test project shows that given foo imports both a and b, and turn b
imports its own vendored version of a, the build breaks.

Importing both a and b doesn't work only when b also exposes the interfaces
(the
generic API interface, not Go interface) from the vendored copy of a.

This is expected, and the solution is high level managing of vendoring, not
a problem
of the vendoring mechanism itself.

So the new standard will be to not vendor packages within a package, correct?

Anyone can turn vendoring off by renaming the directory they have named "vendor"

As someone who imports a third party package that is using vendoring, against this standard, I do not easily have this option. I'd have to convince that package owner that they should remove vendoring, or maintain my own fork.

Do we agree that what I described earlier should not occur? Should the build tool resolve vendor/foo/bar/a for package vendor/fizz/buzz/b, when b itsself has been vendored into another project (what I was describing as deep vendoring)?

I'd like to withdraw my propsoal for pushing back vendoring as a default in Go 1.6. I would like to continue a discussion around how the build tool handles recursive vendoring and how this affects Go 1.7. How should we proceed with this open issue?

On Thu, Nov 12, 2015 at 4:13 PM, Kyle Wolfe notifications@github.com
wrote:

So the new standard will be to not vendor packages within a package,
correct?

No. I don't think Russ meant that. It's perfectly fine to vendor a package
in a package,
if its use is entirely internal.

Anyone can turn vendoring off by renaming the directory they have named
"vendor"

As someone who imports a third party package that is using vendoring,
against this standard, I do not easily have this option. I'd have to
convince that package owner that they should remove vendoring, or maintain
my own fork.

Do we agree that what I described earlier should not occur? Should the
build tool resolve vendor/foo/bar/a for package vendor/fizz/buzz/b, when b
itsself has been vendored into another project (what I was describing as
deep vendoring)?

I don't agree. According to the design docs of the vendoring experiment,
recursive
vendoring has well defined semantic: a given import will always choose the
best
(i.e. longest) match from the list of candidate vendored copies.

I replied to the vendor-inside-vendor example on the mailing list thread. Let's have that discussion there. Closing the issue since the proposal has been withdrawn.