x/tools/cmd/gotype: "could not import" packages

[jgautheron]

gotype fails to import local (not relative) packages within a Docker container.

Context
go is installed in a Docker container, the base image is alpine:3.2.
See the Dockerfile.

Steps
1. Mount the current path on the host dynamically in the container to fit in the GOPATH within the container: let's say my PWD is ~/go/foo/bla on my host, then I run the following command:

$ docker run --rm \
  -v $PWD:/root/go/src/github.com/foo/bla \
  -w /root/go/src/github.com/foo/bla \
  -it mycompany/go bash

2. Run gotype . in the project folder (located in the GOPATH)

Then I get the following errors:

cli.go:8:2: could not import github.com/foo/bla/logger (can't find import: github.com/foo/bla/logger)
cli.go:9:2: could not import github.com/foo/bla/processor (can't find import: github.com/foo/bla/processor)
cli.go:125:2: undeclared name: logger
cli.go:130:4: undeclared name: logger
cli.go:133:3: undeclared name: logger
cli.go:136:7: undeclared name: processor

The project local dependencies can't be imported. The other imports are OK though.

Environment

$ go version
go version go1.5.1 linux/amd64
$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/root/go"
GORACE=""
GOROOT="/usr/lib/go"
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GO15VENDOREXPERIMENT=""
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="1"

[ianlancetaylor]

CC @griesemer @alandonovan

[alandonovan]

The gotype tool assumes that you have recently done a "go install" of all dependency packages that are imported by the source files that it type checks, since it parses the pkg.a object code files produced by the compiler in order to obtain type information. (This limitation is unfortunate and not well advertised.)

(The golang.org/x/tools/go/loader package provides an alternative means of getting type information for dependencies, by loading and type checking the whole program from source. However, gotype doesn't use it, not least because it is not in the standard library.)

[jgautheron]

OK, good to know... thanks for the info.

[FiloSottile]

@alandonovan Just tried to replace my "go install && go test -run=$^" onsave hook with x/tools/cmd/gotype and this made it pointless: I'll fix something in package A, go over to package B that imports A, save, and the result would be inconsistent.

What about having a flag to use golang.org/x/tools/go/loader? Would it make sense? Would you accept a PR to do this?

[griesemer]

@FiloSottile x/tools/cmd/gotype is on life-support only (keep it building for now) since it depends on x/tools/go/types which also is not further developed. Instead, the new versions of both are now in the standard library: The most up-to-date type-checker is go/types, and the directory contains a stand-alone gotype command (see comment in gotype.go for how to build that binary).

Thus, both the library and the gotype command are now independent of x/tools. We don't want to introduce a dependency on x/tools by using x/tools/go/loader.

The long-term plan is to determine a long-term solution/placement for x/tools/go/loader; we are hoping to make some progress on this for 1.7.

[alecthomas]

Is there some reason gotype.go isn't in its own cmd package, and thus go-gettable?

[griesemer]

gotype.go is a small tool mostly for "interactive" testing of go/types;
it's not super-useful on its own (you can always use the compiler). It
seemed easiest to just keep it as a separate package in go/types. It's a
single file so there's no problem in getting it if need be.

• gri

On Wed, Mar 2, 2016 at 6:01 AM, Alec Thomas [email protected]
wrote:

Is there some reason gotype.go isn't in its own cmd package, and thus
go-gettable?

—
Reply to this email directly or view it on GitHub
#12703 (comment).

[alecthomas]

Your use of the word "interactive" is relevant, as gotype is currently very useful for inline linting in text editors (see below). It is the only "linter" that picks up a certain class of errors (like misspelt keywords). Without it, these errors go unreported.

Using the compiler itself for inline linting is not ideal, as you generally don't want to generate artifacts. Additionally it may result in quite lengthy linting times under some circumstances (uncompiled dependencies).

I could simply copy gotype.go into its own repository and go get that, but that has ongoing maintenance issues. I'd prefer not to do this.

Please reconsider!

Linters using gotype:

1. Syntastic (VIM)
2. SublimeLinter
3. Atom

Also, any editor linter using gometalinter also relies on this functionality, including Emacs flycheck and many others.

[griesemer]

@alecthomas Just to make sure I understand you correctly: You are bringing up a separate (different) issue here (gotype not being go-gettable). If that is what you mean with "Please reconsider", please file a separate issue for that. If not, please clarify. Thanks.

[alecthomas]

Ah yes, will do.

[akutz]

FWIW, go test -i is a workaround for the import issue if the issue is with test sources. I just submitted a patch for this issue for the gometalinter tool.

[jayvdb]

Note gotype cmd has now been removed in golang/tools@f5a6ee1

[griesemer]

x/tools/cmd/gotype was removed because we don't want to maintain two slightly different versions. The latest and up-to-date version is in (std/lib) go/types. It's a stand-alone app gotype.go, and must be built with go build gotype.go in that directory, for now. It supports a new flag -c which permits the specification of the compiler that was used to create packages. Importing from source is now possible with -c=source. Thanks.

[jayvdb]

I have created a copy of the old source at https://github.com/jayvdb/gotype, and @coala is now using that as needed by its CI.
If there is any problem with my copy repository from a licensing/etc perspective, feel free to email me, or submit PRs.

[griesemer]

@jayvdb There's no problem with your copy as long as you keep the copyright notice in the source. You may eventually want to move to the latest version which is in (std/lib) go/types/gotype.go (or copy it as needed).

[jayvdb]

re the fork repo, my needs are for regression testing only, so I have no need for the latest version in that repo.
coala can add a deprecation notice, and/or wrap the stdlib version. Added coala/coala-bears#1488 about that.