New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: internal relative paths not working for go modules outside of $GOPATH #27224

Closed
driusan opened this Issue Aug 25, 2018 · 4 comments

Comments

Projects
None yet
5 participants
@driusan
Copy link

driusan commented Aug 25, 2018

Please answer these questions before submitting your issue. Thanks!

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

go version go1.11 dragonfly/amd64

Does this issue reproduce with the latest release?

Yes

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

GOARCH="amd64"
GOBIN=""
GOCACHE="/home/driusan/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="dragonfly"
GOOS="dragonfly"
GOPATH="/home/driusan/go"
GOPROXY=""
GORACE=""
GOROOT="/home/driusan/Code/go"
GOTMPDIR=""
GOTOOLDIR="/home/driusan/Code/go/pkg/tool/dragonfly_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build557340217=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I have a pure go git client at https://github.com/driusan/dgit that I'm trying to add go module support to following the instructions in the release notes. The package has a slightly non-idiomatic directory structure where the root of the directory is "package main", a subpackage named "cmd" has the code for using flag to parse the (overly complex) git command line, and a subpackage named "git" has the library code for actually performing git operations.

There are no external dependencies other than the standard library. Attempting to build outside of $GOPATH adds github.com/driusan/dgit as a dependency instead of using the local subpackage, so I changed all import paths to be relative paths (see https://github.com/driusan/dgit/pull/115/files). It now builds outside of $GOPATH with go 1.10, but go 1.11 results in the error "build github.com/driusan/dgit: cannot find module for path _/home/driusan/Code/dgit/cmd".

Building either inside of $GOPATH results in the error "main.go:12:2: local import "./cmd" in non-local package
main.go:13:2: local import "./git" in non-local package" with both go 1.10 and go 1.11.

What did you expect to see?

Code that compiles with go 1.10 compiles with go 1.11. (Ideally, in a way that it's possible to support both older versions of go and go modules at the same time for my library.)

What did you see instead?

Code that compiles with go 1.10 doesn't compile with go 1.11.

@JeremyLoy

This comment has been minimized.

Copy link

JeremyLoy commented Aug 25, 2018

does the first line of your go.mod file contain module github.com/driusan/dgit?

EDIT: Looking at your PR, it seems your module is just module dgit. Try changing that and see if it works.

@driusan

This comment has been minimized.

Copy link
Author

driusan commented Aug 25, 2018

@JeremyLoy using the proper module name fixes the need for relative imports, but the bug where relative imports started failing with 1.11 still exists

@bradfitz bradfitz changed the title internal relative paths not working for go modules outside of $GOPATH cmd/go: internal relative paths not working for go modules outside of $GOPATH Aug 25, 2018

@bradfitz bradfitz added this to the Go1.12 milestone Aug 25, 2018

@thepudds

This comment has been minimized.

Copy link

thepudds commented Aug 26, 2018

@driusan Not sure if this is what you are hitting, but I think there were some restrictions introduced with modules regarding relative paths.

See #26645 (comment) for example. It is worth reading the the full comment and full issue there, but it includes for example this statement:

In modules, there finally is a name for the subdirectory. If the parent directory says "module m" then the subdirectory is imported as "m/subdir", no longer "./subdir".

Does it sound like you might be hitting that? Or does it seem you are in a different case than what is described in #26645?

@bcmills

This comment has been minimized.

Copy link
Member

bcmills commented Nov 15, 2018

Closing as a duplicate of #26645.

You should be able to use fully-qualified import paths in both GOPATH mode and module mode.

@bcmills bcmills closed this Nov 15, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment