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/go: unclear error message with GO15VENDOREXPERIMENT and import rewriting #12111
Comments
@pwaller You're doing it wrong. There is a restriction (for good reason) when the GO15VENDOREXPERIMENT=1 then import paths are not allowed to explicitly mention /vendor/ paths. This restriction is present for a good reason. It prevents importing paths in two different ways and keeps things a bit saner. Trust me on this. Import path rewriting should never be done into a vendor folder with this GO15VENDOREXPERIMENT on. For the sake of consistency and ecosystem we shouldn't vendor at all by doing import path rewriting. |
Specifically, this is not allowed: https://github.com/pwaller/vendor-collision/blob/a74a28c9c86280739303d927795521a68deee65c/vendor/vendor.org/p/p.go#L4 |
@kardianos that's what I suspected. So my only option is to fork and implore upstream to move to the new way? |
Your issue here is a poster child for why we need a single endorsed way. Different incompatible vendoring methods cause pain. Your new title isn't actually correct. Import path rewriting works great with vendoring, if they are re-written to a folder like internal. I would still advise against it because most tools won't support a way to de-duplicate packages then. https://github.com/kardianos/govendor plays just fine with imports re-written to the internal directory. |
@kardianos did you mis-parse my new title? The new title is about the error message. |
@pwaller Ha ha! Yes, I did. Sorry for the noise. I agree, the error message is not clear. |
I think the error message (from the initial report) is:
What is not clear? What would you like it to say instead? Thanks. |
@rsc I think the part that may be unclear is that it doesn't state "vendor" path segments are disallowed to be explicitly used. This might be clearer to people who use import path rewriting into the vendor folder. maybe. In retrospect, the existing error message is probably fine. |
@rsc after now being familiar with what is going on, I understand the error message clearly and can easily what was wrong. I now had to sit and think for five minutes to understand why I didn't understand at the time. I think the core problem is that it doesn't explain why. It says what is wrong, but it is unclear why it's a problem or how to fix it. At the time searching for the error message was not illuminating either. From a quick search now, just the existence of this issue and the thread on -nuts probably improve someones chances at discovering and understanding what is wrong. |
"import" statements cannot contain vendor paths when GO15VENDOREXPERIMENT is enabled. golang/go#12111 reflect.PkgPath returns the actual package path used by a type. This can include the vendor directory. golang/go#12739 When writing "import" statements using reflect.PkgPath, /vendor/ should be stripped from the import path.
Link to original mailing list post.
Over here, I have a demo package: https://github.com/pwaller/vendor-collision
On go1.5rc1, if you git clone it and do
go build
(notgo get
), you get the following:To clarify: "vendor-collision" refers to the collision of vendoring methods, not packages, or anything like that.
Also, for the record, this is what the package looks like:
main.go
importsvendor.org/p
which directly importsvendor.org/p/vendor/example.com/library
, wherevendor.org/p
should importexample.com/library
under theGO15VENDOREXPERIMENT
regime, butvendor.org/p
's code is in a git submodule. I don't want to pokevendor.org/p
's code if I can avoid it. (And persuading them to change to the new method will break people's ability to easily build on go1.4)/cc @davecheney
The text was updated successfully, but these errors were encountered: