When import rewriting meets GO15VENDOREXPERIMENT=1

[Peter Waller]

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`, we'll come to that as a separate problem), 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

This is a problem. I have become very productive using git submodules to refer to specific commits in other repositories. I'm not keen to require maintaining our own forks to fix the problem.

Questions:

1) golang "must be imported as" gives 3 hits on duckduckgo:

https://duckduckgo.com/?q=golang+%22must+be+imported+as%22&t=canonical

OK! That's an extreme example, but generally the message isn't very helpful (I can't tell *why* that is a rule, nor can I trivially find references to it). Could the message be improved and/or some prominent documentation live somewhere?

(In case you're wondering, there are 7 hits for that on Google, none of which are helpful, and relaxing/mixing up the search doesn't help either).

2) How can I build vendor-collision?

I assume I am forced at the moment go re-rewrite the imports to remove vendor.org/p's rewriting? Or persuade vendor.org/p to avoid rewriting (which then makes it difficult to build on <go1.5). Is there an alternative I haven't considered?

3) Is this something that can be improved in the go build logic?

I don't know, because I can't easily find the rationale for the error message.

I found this: https://github.com/golang/go/issues/11864 which implies I'm not the first to hit a problem of this nature.

# Go get as a separate problem

As a curiosity, if you `go get -v` the package, it tries to fetch vendor.org/p from the internet. Why does it do that, given that it is available in the ./vendor directory? Is this expected?

[Peter Waller]

 I realise in hindsight I chose a bad name for the repository.

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)

[Dave Cheney]

Please log a bug so this is not lost before the imminent go 1.5 release.

Thank

Dave

Ps. I don't think there is a workaround, the go tool has a bug.

[Peter Waller]

https://github.com/golang/go/issues/12111

[Peter Waller]

Should I file a separate bug for the `go get` issue (it unexpectedly fetches the vendor.org repository even though it's available in /vendor)? Is that also a bug?

[Dave Cheney]

Given how close the release is, I'd log a separate bug. Worst that can happen is it gets closed as a duplicate.

[Peter Waller]

Also filed:

cmd/go: go get fetches packages which are vendored
https://github.com/golang/go/issues/12112

On 11 August 2015 at 11:08, Dave Cheney <da...@cheney.net> wrote:

Given how close the release is, I'd log a separate bug. Worst that can happen is it gets closed as a duplicate.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Theophanes]

Hi Peter,

When GO15VENDOREXPERIMENT = 1 then it is illegal to have an import path explicitly contain /vendor/ elements. Error messages could be improved. This line is wrong:

https://github.com/pwaller/vendor-collision/blob/a74a28c9c86280739303d927795521a68deee65c/vendor/vendor.org/p/p.go#L4

-Daniel

[Peter Waller]

That's what I suspected. So my only option is to maintain a fork and implore vendor.org to update to the GO15VENDOREXPERIMENT way?

--

[Peter Waller]

Let's continue the discussion in https://github.com/golang/go/issues/12111.

[Peter Waller]

In the heat of battle I forgot to check the basics: the checkout of my upstream was out of date and they had already fixed it! Let that be a lesson for me...

https://github.com/fsouza/go-dockerclient/issues/348#issuecomment-129879693

I do however still think that the error message needs improving, so https://golang.org/issues/12111 still stands and has been renamed to "cmd/go: Poor error message with GO15VENDOREXPERIMENT and import rewriting".