New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
go/build: creating vendor/a/b/c implicitly vendors a and a/b too #13832
Comments
I'm going to mark this as Go 1.6, as it's blocking x/tools/cmd/bundle from being able to update the std copy of http2 from x/net. |
Hmm. The vendor spec is very clear:
But obviously that's not good enough. I'm surprised this is the first we've noticed this. I can't decide if that's good. The a/b directory in your example is non-empty: it contains c. It's not entirely clear what to do. I guess if there are no .go files at all (not even ones with exclusionary build tags) then we could ignore the directory. I'll try that. |
FWIW, this was an effective fix:
EDIT: although now that you mention it, I don't know why this worked since the subdirectory counts as an entry too. Will investigate. |
@alandonovan, how does that work? Doesn't a/b contain a/b/c? Am I misunderstanding what readDir does? It looks like it calls ioutil.ReadDir. Maybe you overrided the default with a broken ctxt.ReadDir function set that doesn't return subdirectories? |
See my EDIT: I don't yet know why it seems to work. |
I still can't explain it. Consider my patch retracted, and sorry for the noise. |
CL https://golang.org/cl/18644 mentions this issue. |
The AllowVendor logic in (*build.Context).Import checks for a directory called vendor/a/b when importing a package "a/b". If only package "a/b/c" was vendored, the directory a/b must exist but will be empty, causing Import not to find the real (unvendored) package.
Import should check for non-empty directories. This logic differs from the usual (non-vendored) case.
The text was updated successfully, but these errors were encountered: