Skip to content
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

Closed
pwaller opened this issue Aug 11, 2015 · 9 comments
Closed
Milestone

Comments

@pwaller
Copy link
Contributor

pwaller commented Aug 11, 2015

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 (not go get), you get the following:

$ go build -v
package github.com/pwaller/vendor-collision
    imports vendor.org/p
    imports vendor.org/p/vendor/example.org/library: must be imported as example.org/library

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:

~/.local/src/github.com/pwaller/vendor-collision$ tree
.
├── main.go
└── vendor
    └── vendor.org
        └── p
            ├── p.go
            └── vendor
                └── example.com
                    └── library
                        └── library.go

6 directories, 3 files

main.go imports vendor.org/p which directly imports vendor.org/p/vendor/example.com/library, where vendor.org/p should import example.com/library under the GO15VENDOREXPERIMENT regime, but vendor.org/p's code is in a git submodule. I don't want to poke vendor.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

@kardianos
Copy link
Contributor

@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.

@kardianos
Copy link
Contributor

@pwaller
Copy link
Contributor Author

pwaller commented Aug 11, 2015

@kardianos that's what I suspected. So my only option is to fork and implore upstream to move to the new way?

@pwaller pwaller changed the title cmd/go: GO15VENDOREXPERIMENT and import rewriting do not mix cmd/go: Poor error message with GO15VENDOREXPERIMENT and import rewriting Aug 11, 2015
@kardianos
Copy link
Contributor

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.

@pwaller
Copy link
Contributor Author

pwaller commented Aug 11, 2015

@kardianos did you mis-parse my new title? The new title is about the error message.

@kardianos
Copy link
Contributor

@pwaller Ha ha! Yes, I did. Sorry for the noise. I agree, the error message is not clear.

@ianlancetaylor ianlancetaylor added this to the Go1.6 milestone Aug 11, 2015
@rsc
Copy link
Contributor

rsc commented Nov 5, 2015

I think the error message (from the initial report) is:

$ go build -v
package github.com/pwaller/vendor-collision
    imports vendor.org/p
    imports vendor.org/p/vendor/example.org/library: must be imported as example.org/library
$ 

What is not clear? What would you like it to say instead? Thanks.

@rsc rsc changed the title cmd/go: Poor error message with GO15VENDOREXPERIMENT and import rewriting cmd/go: unclear error message with GO15VENDOREXPERIMENT and import rewriting Nov 5, 2015
@kardianos
Copy link
Contributor

@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.

@pwaller
Copy link
Contributor Author

pwaller commented Nov 10, 2015

@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.

@pwaller pwaller closed this as completed Nov 10, 2015
KevinPike pushed a commit to doubledutch/mock that referenced this issue Feb 26, 2016
"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.
@golang golang locked and limited conversation to collaborators Nov 10, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants