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
cmd/doc: issues related to vendor ambiguity #12423
Comments
I cannot reproduce the first problem. Not sure why:
The vendoring issues are very unclear to me, and I think there are a number of other issues around tooling and vendoring that need to be resolved. I see no reason this needs to be done soon, so I will downgrade to Go1.6 from Go1.6Early and remove myself as assignee. |
The reason I can't reproduce the WARNING is that the package is not installed in a vendored directory and I don't know why it is in your situation. So there likely is an issue here, and maybe all it takes to resolve is that the WARNING be prefixed by a check that there is no "/vendor/" in the actual path. But also: I tried an example that is in a vendor directory and it works fine:
I believe the real issue here is indeed priority, but I am not sure what the right answer is. |
CL https://golang.org/cl/17691 mentions this issue. |
This is a simple change to the command that should resolve problems like finding vendored packages before their non-vendored siblings. By searching in breadth-first order, we find the matching package lowest in the hierarchy, which is more likely to be correct than the deeper one, such as a vendored package, that will be found in a depth-first scan. This may be sufficient to resolve the issue, and has the merit that it is very easy to explain. I will leave the issue open for now in case my intuition is wrong. Update #12423 Change-Id: Icf69e8beb1845277203fcb7d19ffb7cca9fa41f5 Reviewed-on: https://go-review.googlesource.com/17691 Reviewed-by: Russ Cox <rsc@golang.org>
The new rules fixed the immediate problem I was running into. |
Test case:
I get:
There are three issues.
First, import comments are no-ops in vendor source trees, so the WARNING should be omitted.
Second, the import statement on the first line should probably give the full path of the selected package (golang.org/x/arch/vendor/rsc.io/pdf). Even though that's not how a source file would import it, the expanded path is what the tools like "go list" show. Perhaps to avoid confusion the line could drop the "import", so not:
but instead:
Third, there should be some kind of prioritization that depends on where in the source tree "go doc" is run. If run in $GOPATH/src/golang.org/x/arch/x86, then absolutely that package is a good resolution for "go doc pdf.Text". But outside $GOPATH/src/golang.org/x/arch, that package is not importable, so if there is non-vendored copy or a closer vendored copy, that should be preferred. In my case, plain $GOPATH/src/rsc.io/pdf should take priority over the vendored arch copy, again possibly unless run inside the arch subtree.
The text was updated successfully, but these errors were encountered: