reflect: Type.PkgPath() doesn't return proper import path for vendored import

[szank]

Hi,
We were using reflect package to get the import path of some of our dependencies. We are using
GO15VENDOREXPERIMENT.

When we call PkgPath() on a Type interface acquired from an instance of a struct from the codec package (github.com/ugorji/go/codec) we get import path :
bitbucket.org/{our_project_dir}/vendor/github.com/ugorji/go/codec

This is not in line with the PkgPath() call documentation, and we are using those import paths to generate a import clause for our generated go code.
The result looks like this :

package example

import(
    bitbucket.org/{our_project_dir}/vendor/github.com/ugorji/go/codec
    {...}
)
{...}

This file clearly doesn't compile. Could you please fix the behaviour of the PkgPath() call when the project is using GO15VENDOREXPERIMENT?

[minux]

I think the value returned by PkgPath is reasonable because
it uniquely identifies the package.

Just returning "github.com/ugorji/go/codec" doesn't always
work because there could be different versions of the package
under different vendor directories in the same program.

Consider this project file layout:
prjA/
pkg1/
vendor/
github.com/ugorji/go/codec/
vendor/prjB/
vendor/
github.com/ugorji/go/codec/
pkg2/

Both prjA/pkg1 and vendor/prjB/pkg2 will use their own version of
github.com/ugorji/go/codec, But those two packages are different,
PkgPath method must return different values.

The example might be contrived, but it illustrates the subtlety of
vendoring packages without import path rewriting.

Because this kind of vendoring is explicitly supported by the go
tool, I don' think we can change PkgPath to strip the prefix. You'd
better deal with it in your generator.

[ugorji]

@minux Based on the documentation, the PkgPath is the import path.

Documentation states:

// PkgPath returns a named type's package path, that is, the import path
// that uniquely identifies the package, such as "encoding/base64".
// If the type was predeclared (string, error) or unnamed (*T, struct{}, []int),
// the package path will be the empty string.
PkgPath() string

The vendor implementation should be transparent/invisible at runtime.
I would think that the PkgPath of a type should always mirror the import
path in the go file, as this is what is reasonably expected, and hides the
implementation details of vendoring.

[minux]

I don't think it's possible for the vendoring experiment to be transparent. Do you think one vendored package should be allowed to modify the unexported fields of another vendored copy of the same package? After introducing the vendoring experiment, the import path can no long uniquely identify a package.

[rsc]

This is working as intended. Quoting golang.org/s/go15vendor:

If there is a source directory d/vendor, then, when compiling a source file within the subtree rooted at d, import "p" is interpreted as import "d/vendor/p" if that exists.

When you ask about the package in question you find out is not the real one but a vendored copy. This is true, and it is correct behavior.

[dmitshur]

I had the same question, and this issue answered it.