plugin: gopath type != vendor type

[fsenart]

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version go1.8rc3 linux/amd64

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/fsenart/projects"
GORACE=""
GOROOT="/home/fsenart/tools/go1.8rc3"
GOTOOLDIR="/home/fsenart/tools/go1.8rc3/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build101924921=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

What did you do?

If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.

Scenario:

1. Build a main program with some dependency located in the GOPATH
2. Build a plugin program with the same dependency vendored
3. Load the plugin from main

Result:

• At runtime, the GOPATH dependency is not the same as the vendored depedency.

// $GOPATH/src/issues/issue_vendor/main .go

package main

import (
	"foo"
	"plugin"
	"reflect"
)

func main() {
	p, err := plugin.Open("plugin.so")
	if err != nil {
		panic(err)
	}
	f, err := p.Lookup("F")
	if err != nil {
		panic(err)
	}

	println(reflect.TypeOf(f).Elem() == reflect.TypeOf((*foo.Bar)(nil)))
}

// $GOPATH/src/issues/issue_vendor/plugin.go

package main

import "C"
import "foo"

var F *foo.Bar

// Copy the file one time in the GOPATH and one time in the vendor directory
// $GOPATH/src/foo/bar.go
// $GOPATH/src/issues/issue_vendor/vendor/foo/bar.go

package foo

type Bar struct{}

# $GOPATH/src/issues/issue_vendor/Makefile

test1: build1
	@./main

test2: build2
	@./main

build1: clean
	@go build -o main main.go
	@go build -buildmode=plugin -o plugin.so plugin.go

build2: clean
	@mv vendor _vendor
	@go build -o main main.go
	@mv _vendor vendor
	@go build -buildmode=plugin -o plugin.so plugin.go

clean:
	@rm -rf main

What did you expect to see?

• make test1 should print true
• make test2 should print true

What did you see instead?

• make test1 prints true
• make test2 prints false

[fsenart]

@ianlancetaylor is there any chance to add this issue to the 1.8.1 milestone as it makes the usage of vendoring nearly impossible in the context of plugins?

[ianlancetaylor]

Adding the 1.8.1 milestone to this issue won't fix the problem. When and if we have a fix on tip, then if the fix is simple and safe, we can consider adding it to 1.8.1.

[edaniels]

As mentioned in #19233, this sounds like the behavior described at #12432. Unless this behavior is set to change in 1.9, this seems like a non-issue, albeit annoying in the context of plugins.

[fsenart]

@edaniels it really seems like the behavior you mentioned but the nuance resides in the fact that this issue happens on run time. I understand that this is the "plugin" version of the behavior, but this is also far more annoying for end users as it can't be detected at compile time.
Plugins come with a lot of advantages but also open the pandora's box. IMHO, the main advantage is to allow the separation between a core program and a myriad of run time functionalities developed by different folks but this kind of issues constraint both parties to know about each others and conform to a set of common dependencies rules.
Maybe we should come up with a freshen look about vendoring in the context of plugins.

[edaniels]

I totally agree. It's probably a discussion for another issue but it seems like this is an issue for vendoring in general and maybe the go tool chain should be more aware of package identity in the future. To make plugins more useful something will need to be done.