vendoring + canonical import path

[Nigel Tao]

I'm not overly familiar with the corner cases for vendoring, but I
think that this problem below is a different problem than the recent
"A tricky (impossible?) situation with common packages and vendoring"
golang-nuts thread.

The github.com/golang/snappy package defines a canonical import path.
Its package clause looks like:

package snappy // import "github.com/golang/snappy"

This is similar to what the golang.org/x/... packages do, such as:

package webp // import "golang.org/x/image/webp"

There's a PR filed (https://github.com/golang/snappy/pull/28) to
remove that meaningful comment for package snappy, because when
vendoring, "go test ./..." does not work in that directory:

$ go test ./... can't load package: package
mycode/vendor/github.com/golang/snappy: code in directory
mycode/vendor/github.com/golang/snappy expects import
"github.com/golang/snappy"

Is this a bug in the go tool, or is this working as intended, and
there is simply some combination of vendoring, canonical import paths,
and go tool relative paths that combine badly?

[David Symonds]

I thought those import declarations were meant to be only enforced
relative to the appropriate containing dir, either $GOPATH/src or a
vendor/ dir.

Is the bug reporter using an older version of Go? It's possible that
it only works correctly with Go 1.6+.

[Andrew Gerrand]

What Dave said is my understanding of how it should work.

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