@bcmills @jayconrod @matloob

@leventov Could you be more specific? What's an example of a package you expected to be vendored? What message should have been printed?

go mod vendor includes packages imported directly or indirectly by packages in the main module and their tests on any platform. If a package wasn't vendored, it's because it's not imported. It's difficult to come up with a list of packages that weren't imported, so we probably can't do this, but I want to make sure we understand your situation.

Some packages are not vendored (despite being imported) because "build constraints exclude all Go files". So it would be helpful to print exactly that, ideally with the list of constraints imposed by the Go files in the package that are not satisfied.

go mod vendor ignores most build constraints though. It should included packages needed to build packages in the main module on any platform.

If you find that's not the case, it may be a bug, so please give a reproducible example.

In my case the reason (apparently) why a package was not included was because go.mod of the "receiver" module (i. e. the module into where I was vendoring) was specifying go 1.12. When I updated that line to go 1.14, I was able to successfully vendor the package that I wanted. The problem was that nothing whatsoever was pointing me to that fix, I actually noticed that I had an outdated go 1.12 statement by chance.

@leventov The go version affects whether the vendor directory may be used automatically (that is, whether -mod=vendor needs to be passed to build commands), but it shouldn't affect the set of packages that go mod vendor copies into the vendor directory. Could you give an example where this is happening?

I'm not interested in that specific problem, because it is already solved for me. I opened this issue as a meta issue: there should be a way to debug problems like that, whether due to bugs in golang tooling or legitimate behaviour. I was relatively lucky to notice a faulty directive quickly, but I didn't have any means at all to inspect the problem.

I'm closing this, since I don't think there's anything we can reasonably do here.

Printing packages that aren't vendored means building a list of packages that weren't imported. Building that list would mean fetching modules we wouldn't normally fetch, possibly encountering new errors. The message we would print next to each package would be something like "not imported directly or indirectly by packages in the main module", which doesn't seem useful.

As I've said, the set of packages that are vendored should not depend on the go version or build constraints. If you find that's not the case, please open a new issue with a reproducible example.