I tried on darwin/amd64 and windows/amd64 and was unable to reproduce this problem. Specifically, I created $GOPATH/src/buggy/p.go containing:

package main
import _ "github.com/mattn/go-sqlite3"
func main() {}

and then I ran:

cd $GOPATH/src
go get github.com/mattn/go-sqlite3
mkdir buggy/vendor
mv github.com buggy/vendor

and then I ran:

go install -v buggy
echo >>buggy/p.go
go install -v buggy

and the rebuild of buggy does not rebuild go-sqlite3. If I change p.go to say package buggy, then go install -v buggy still doesn't rebuild go-sqlite3.

I'd like to fix this but I can't without reproducing it. Can you link to the exact code you are using and show the exact commands you are running? Thanks.

With those steps, the issue doesn't appear. I modified them to reproduce the issue by changing

mv github.com buggy/vendor to cp -R github.com buggy/vendor
go install -v buggy to go install -v github.com/mattn/go-sqlite3

As the unvendored source is still in src/, it looks like the go install is installing that when explicitly specifying the package name. Removing the unvendored source causes a package not found error.

Some tools, at least govendor, don't remove the unvendored source when vendoring a package. Perhaps installing a package by name when both unvendored and vendored source are available should result in an error due to ambiguity?

Great, thanks. As I understand it now, the report concerns this command sequence:

go install -v github.com/mattn/go-sqlite3
go install -v buggy

Specifically, the report is that the first command installs the non-vendored go-sqlite3 and the second one builds and installs the vendored copy.

If so, that's working as intended. On the go command line, paths are always interpreted relative to GOROOT/GOPATH roots, not vendor directories. The canonical path for a vendored package includes the .../vendor/ prefix even though source code-level import references do not. That is, on the command line, 'github.com/mattn/go-sqlite3' always means the unvendored copy of go-sqlite3, while buggy/vendor/github.com/mattn/go-sqlite3 is a vendored copy. You'll see these expanded paths in the output of 'go list -json' or 'go list all' as well.

What would be unintended is if the second of any of these command pairs printed anything at all (the first should do all the work):

go install -v buggy
go install -v buggy

go install -v buggy/vendor/github.com/mattn/go-sqlite3
go install -v buggy/vendor/github.com/mattn/go-sqlite3

go install -v github.com/mattn/go-sqlite3
go install -v github.com/mattn/go-sqlite3

Can you confirm that on your system those are all correctly doing nothing the second time? Thanks.

Ah, I see what you mean. I expected package names to check the vendor directory first rather than prefixing them with buggy/vendor/. That makes sense.

The pairs you posted are working as they should.

Maybe when vendored packages have a naming collision with an unvendored package present in the same GOPATH, it would worth putting a warning when building to avoid this kind of confusion?

I'm closing this issue as it's solved. Thanks!