-
Notifications
You must be signed in to change notification settings - Fork 18k
vendor spec: package visibility #14031
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
Comments
https://golang.org/s/go15vendor says "The short form must always be used: no import path can contain “/vendor/” explicitly." That seems to clearly disallow importing "vendor/golang.org/x/net/http2/hpack" to me. |
Do you think that maybe this should be thought about for Go1.6? Personally, this issue doesn't affect me, but if we release Go1.6 with GO15VENDOREXPERIMENT enabled by default, then it will probably be harder to change specification related things in Go1.7 when the impact becomes wider. |
@mdempsky, you're right. I think that does make it pretty clear that vendor should not be visible then. |
This really seems like a bug that should be fixed for 1.6. Note that it happens with non-stdlib vendored packages as well, so moving vendor to internal in the stdlib for 1.6 doesn't hide the issue completely. |
Over to @rsc... |
I think this only happens when you use |
I can confirm @cespare on this, I can build or run the file directly, but I can't build it like a package: |
Thanks for the report. |
Copying from golang-dev
The vendor specification doesn't seem to speak much about the visibility of the vendored packages. Thus, should vendor be treated in similar ways to internal?
As it currently is, the following program compiles under go1.6beta2 (with the vendor experiment on):
Is this expected behavior? It seems kind of odd that I can import hpack as part of the "standard" library.
This is related to #13961 and #13929.
The text was updated successfully, but these errors were encountered: