Skip to content
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: "unrecognized import path" for local packages after updating to go1.13 #34117

Open
nichoriverae opened this issue Sep 5, 2019 · 9 comments

Comments

@nichoriverae
Copy link

commented Sep 5, 2019

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

$ go version
1.13

Does this issue reproduce with the latest release?

Yes

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

$ go env

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/nrivera/Library/Caches/go-build"
GOENV="/Users/nrivera/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/nrivera/go"
GOPRIVATE=""
GOPROXY="off"
GOROOT="/usr/local/Cellar/go/1.13/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.13/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/sf/74kcmjp94lzc1567ysxwb0z15rwk9k/T/go-build433853316=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I attempted to go run an application as before, but ran into an unrecognized import path error. Previously with 1.12 I did not have an issue. These are imports from sub packages within a main package.

running
go get -u ./...
returns:
package _/*/src: unrecognized import path "_/*/src" (import path does not begin with hostname)

What did you expect to see?

That local packages don't need a hostname, and they don't fail to "get".

What did you see instead?

"import path does not begin with hostname"

@nichoriverae nichoriverae changed the title Unrecognized import path "<user directory>/<package directory>/<some subpath>" (import path does not begin with hostname) Unrecognized import path for local packages after updating to go1.13 Sep 5, 2019

@bcmills

This comment has been minimized.

Copy link
Member

commented Sep 5, 2019

That error message comes from here:

return nil, errors.New("import path does not begin with hostname")

@bcmills bcmills changed the title Unrecognized import path for local packages after updating to go1.13 cmd/go: "unrecognized import path" for local packages after updating to go1.13 Sep 5, 2019

@bcmills bcmills added this to the Go1.14 milestone Sep 5, 2019

@bcmills

This comment has been minimized.

Copy link
Member

commented Sep 5, 2019

Can you provide a concrete source file that reproduces the issue? There were certainly changes around that code path in 1.13 that may be related, but my understanding (from #26645 (comment) and other previous discussions) is that relative imports have never worked with go get.

This may also be related to #12385.

@thepudds

This comment has been minimized.

Copy link

commented Sep 5, 2019

@nichoriverae just to confirm, is it correct that are you not using modules?

One change in Go 1.13 is GO111MODULE=auto (which is the default value if not explicitly set) now turns on module mode whenever you are running the go command inside of a directory tree with a go.mod file — even if the current directory is within GOPATH/src. This means module mode happens in more cases than in Go 1.12. (See the Go 1.13 release notes for more details).

@nichoriverae

This comment has been minimized.

Copy link
Author

commented Sep 5, 2019

@thepudds the project is using modules

@bcmills I'm attempting to recreate the error using a fresh directory now, I'll post a gist when I get it to the same state. Just to reaffirm, there are no relative imports and the failure point is on submodules within the main package.

@nichoriverae

This comment has been minimized.

Copy link
Author

commented Sep 5, 2019

go vet seems to be looking in GOPATH and GOROOT:

<package>/src/*/<file>:14:2: cannot find package "github.com/golang-migrate/migrate/v4/database/mysql" in any of:
        /usr/*/github.com/golang-migrate/migrate/v4/database/mysql (from $GOROOT)
        /Users/*/github.com/golang-migrate/migrate/v4/database/mysql (from $GOPATH)
@nichoriverae

This comment has been minimized.

Copy link
Author

commented Sep 5, 2019

$ and a simple go get ./...

package <package>/src/config: unrecognized import path "<package>/src/config" (import path does not begin with hostname)
@nichoriverae

This comment has been minimized.

Copy link
Author

commented Sep 5, 2019

@bcmills this repo repoduces the error. Granted, it's not using the import that is failing, but the go get command gives me the same error.
https://github.com/nichoriverae/Go-Issue-34117

@thepudds

This comment has been minimized.

Copy link

commented Sep 5, 2019

@nichoriverae Thank you for putting that repo together.

For that repo, what is the exact command sequence that fails, and what is the error you currently get?

go get github.com/nichoriverae/Go-Issue-34117 fails complaining about a mismatch with parsing go.mod: module declares its path as: main, but that's expected, and I think not the error in question here.

Doing git clone https://github.com/nichoriverae/Go-Issue-34117, cd'ing to the resulting directory, and doing go get ./... and go get -u ./... do not seem to complain, so I am probably doing something wrong.

@nichoriverae

This comment has been minimized.

Copy link
Author

commented Sep 6, 2019

I'm under the impression these issues are happening because of GOPROXY and my corporate network settings. I changed the environment variable to "direct" and that solved most of my issues.

@thepudds I tried the repo on another machine that had a fresh go1.13 install and it didn't give me any problems either, which makes me assume that it is indeed the corporate settings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.