This is a refinement of #16580. The bug described there is about code that is temporarily invalid due to the types in the "a/vendor/b" package being different from those in the "b" package. This bug is about what's likely a less controversial problem—that the eg command writes import declarations that include "/vendor/".

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

go version go1.7.1 darwin/amd64, with golang/tools@c2ef61f

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

$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/rhys/work"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/49/zmds5zsn75z1283vtzxyfr5hj7yjq4/T/go-build542934852=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"

What did you do?

I ran eg against a file with access to a "vendor" directory. The template rewrote a function call from one provided by a package in the GOPATH to one provided by a package under the "vendor" directory. The contents of the GOPATH are shown (far) below.

What did you expect to see?

I expected eg's rewrite to result in valid import declarations, containing only the section of the path after the "vendor" segment.

What did you see instead?

The import declarations written by eg include a "/vendor/" segment.

Here are the contents of the GOPATH where I've reproduced the issue:

./src/dep0/dep0.go:

package dep0

func C() {}

func D() {}

./src/prog/vendor/dep1/dep1.go:

package dep1

func E() {}

./src/prog/main.go:

package main

import (
    "dep0"
)

func example() {
    dep0.C()
    dep0.D()
}

And the template:

package eg

import (
    "dep0"
    "dep1"
)

// Test of adding a dependency that is found via a "vendor" directory

func before() { dep0.D() }
func after()  { dep1.E() }