<p dir="auto">go1.6 gotype seems to be unaware of vendoring</p>
<ol dir="auto">
<li>What version of Go are you using (<code class="notranslate">go version</code>)?<br>
1.6</li>
<li>What operating system and processor architecture are you using (<code class="notranslate">go env</code>)?<br>
GOARCH="amd64"<br>
GOBIN=""<br>
GOEXE=""<br>
GOHOSTARCH="amd64"<br>
GOHOSTOS="linux"<br>
GOOS="linux"<br>
GOPATH="/home/john/src/gocode"<br>
GORACE=""<br>
GOROOT="/home/john/opt/go"<br>
GOTOOLDIR="/home/john/opt/go/pkg/tool/linux_amd64"<br>
GO15VENDOREXPERIMENT="1"<br>
CC="gcc"<br>
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"<br>
CXX="g++"<br>
CGO_ENABLED="1"</li>
<li>What did you do?<br>
john@ebola:~/src/gocode/src/github.com/the42/bevaddress$ gotype bevaddress.go</li>
</ol>
<p dir="auto">The tree is<br>
john@ebola:~/src/gocode/src/github.com/the42/bevaddress$ tree -d<br>
.<br>
├── Godeps<br>
└── vendor<br>
└── github.com<br>
├── gorilla<br>
│   └── websocket<br>
└── lib<br>
└── pq<br>
└── oid</p>
<p dir="auto">8 directories</p>
<ol dir="auto">
<li>What did you expect to see?<br>
no error (go build works)</li>
<li>What did you see instead?<br>
bevaddress.go:9:2: could not import github.com/gorilla/websocket (can't find import: github.com/the42/bevaddress/vendor/github.com/gorilla/websocket)<br>
bevaddress.go:10:4: could not import github.com/lib/pq (can't find import: github.com/the42/bevaddress/vendor/github.com/lib/pq)<br>
bevaddress.go:18:16: undeclared name: websocket</li>
</ol>
<p dir="auto">It is common to use go/types is as part of a go generate command<br>
or other command line tool to introspect a Go package.</p>
<p dir="auto">The go tool goes to some lengths to ensure that whenever<br>
you operate on a package, it builds the source for that<br>
package into object form before using it, so you don't<br>
end up using symbol information that's out of date with respect<br>
to the source.</p>
<p dir="auto">When using go/types from a command line tool, you<br>
don't have that luxury, and it's not necessarily appropriate<br>
to call "go install" automatically.</p>
<p dir="auto">I believe that a better way would be for the default<br>
importer to use the object file data only if it's newer<br>
than the source files, otherwise fall back to using the<br>
source directly. Or at least it would be nice to have<br>
that option, so that it's easy to make go generate<br>
utilities operate on the up to date code.</p>
<p dir="auto">I hope this could be considered before Go 1.5 as<br>
we won't be able to change this behaviour after then.</p>