cmd/go: vendoring a package with the same name as a package in GOROOT leads to inconsistent imports #12172
Comments
azylman
changed the title
This is exactly what is supposed to happen. Vendoring affects imports in the directory tree rooted just above the vendor directory. It does NOT reach out and change imports elsewhere in your program. You can control which net/http your code uses. You cannot control which net/http other people's code uses. In general this is a very hard problem: what if two different packages you are importing both vendored their own net/http? If the semantics were that vendoring replaced every instance in the whole binary, which one should be used? Not having those semantics avoids that question. Quoting golang.org/s/go15vendor:
|
go version: go 1.5rc1
architecture: linux-amd64
When you have a vendored package with the same name as a package in GOROOT (e.g.
net/http), behavior is inconsistent. It seems like other packages within GOROOT get the package in GOROOT, but things not in GOROOT (e.g. your app, other vendored packages) get the vendored version.Here's a gist: https://gist.github.com/azylman/305ad6172dd884aaaed4
In this gist, we have a vendored "net/http" and import "net/http" and can use our vendored version, but importing "net/http/httptest" or "net/http/httputil" still work
Here's a Google Group discussion for context: https://groups.google.com/forum/#!topic/golang-nuts/PFaB0hon6ug
I'm not sure what the expected behavior is - if vendoring a package that's the same as GOROOT should work or not, but I'm guessing this inconsistent behavior is not expected.
The text was updated successfully, but these errors were encountered: