Avoid saving/getting "main" subdirectories of dependencies (at least in vendor/ mode)

[rasky]

Some packages have subdirectories that contain "main" packages; common cases are either providing examples of usage (see https://github.com/Sirupsen/logrus for instance), or command-line applications that use the library itself (see https://github.com/rasky/multigz). Notice that it's possible for these main packages to import third-party libraries, which might not be otherwise a dependency of the library itself. For instance, https://github.com/rasky/multigz/blob/master/cmd/multigz/multigz.go imports pflag and atime, both of which are not a dependency of multigz the library, but just of this specific main package.

When working in a pure Go 1.5 vendoring scenario, godep does not vendor these additions libraries (pflag/atime in the example) and I believe it is right in doing so, as they are not required for using the library themselves. Unfortunately, this breaks go test ./..., which exits with an error:

vendor/github.com/rasky/multigz/cmd/multigz/multigz.go:16:2: cannot find package "github.com/djherbis/atime" in any of:
    /home/ubuntu/.go_project/src/myproj/vendor/github.com/djherbis/atime (vendor tree)
    /usr/local/go/src/github.com/djherbis/atime (from $GOROOT)
    /home/ubuntu/.go_project/src/github.com/djherbis/atime (from $GOPATH)

I'm not even sure why go test cares about dependencies that main package; there are not even test files in that directory in the first place.

Anyway: do you think it would make sense for godep to avoid vendoring those main packages altogether? They don't serve any purpose in the vendor directory after all, as they cannot be imported. Skipping them would be similar (conceptually) to avoid copying _test files, which godep does already.

[freeformz]

It's because you specified ./... with go test. Which means you are running all of your tests and all tests inside the vendor/ directory. Go test needs to build the code first so you run into this error. In go 1.5+ you can't import main packages (you could previously), so I think it makes sense for us to not vendor them. I won't be able to look into this more until later in the week / early next week, but will do so.