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: error loading subpackage with pathMajor suffix #31605

Open
arnottcr opened this issue Apr 21, 2019 · 2 comments

Comments

Projects
None yet
2 participants
@arnottcr
Copy link

commented Apr 21, 2019

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

$ go version
go version go1.12.4 linux/amd64

Does this issue reproduce with the latest release?

yes

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

go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/user/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/user/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/lib/go"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/tmp/test/go.mod"
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-build918357550=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Tried to fetch a poorly named subpackage at v1.2.0:

go get github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4/sub/v4

What did you expect to see?

Successfully fetch the v1.2.0 module:

go: finding github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4 v1.2.0

What did you see instead?

go: finding github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4/v2/sub/v3 v3.0.0
go: finding github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4/sub/v3 v3.0.0
go: finding github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4/v2 v2.0.0
go: finding github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4 v1.2.0
go: finding github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4/sub/v4 v4.0.0
go: github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4/sub/v4@v4.0.0: missing github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4/sub/go.mod and .../v4/go.mod at revision sub/v4.0.0
go: error loading module requirements

While I concede that this repo is built to test edge cases and collisions in module resolution, there is only one correct resolution for sub/v4 => github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4@v1.2.0/sub/v4. Is this expected, since I know many google APIs use vN packages to track the API version, not the library version.

Also, this resolution scheme pulls in a number of versions that I would not expect (v2/sub/v3.0.0, etc.). Should it not check two, then stop:

  • github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4/sub/v4 v4.x.x
  • github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4 v1.x.x
@thepudds

This comment has been minimized.

Copy link

commented Apr 22, 2019

I know many google APIs use vN packages to track the API version, not the library version.

I believe in general that is usually not a major issue in practice. I believe the way it is supposed to work in terms of restrictions around packages named /v2 or /vN is briefly described in #28435 (comment) and #28435 (comment). A repo named github.com/my/v4 with a module named github.com/my/v4 is problematic, for example, but a package named github.com/some/repo/pkg/v4 living inside a module named github.com/some/repo should not be a problem, at least in theory.

That said, this is a complex example, so maybe what you are seeing is a bug, or maybe it is a correct but non-obvious result (including because the repo itself has a fairly complex setup with a complex history).

There is a sub/v4.0.0 tag at https://github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4/tree/sub/v4.0.0, but that has a /v2-based go.mod and only nests a /v4-based go.mod within a /v2 subdirectory, which might be the problem the error is complaining about.

Alternatively, perhaps the presence of
https://github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4/blob/v1.2.0/sub/v3/go.mod is causing it to look for github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4/sub/v4/go.mod when you do go get github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4/sub/v4, but that is just a shot in the dark.

On the other hand, this seems to work:

go get github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4/sub/v4@v1.2.0

@thepudds thepudds changed the title error loading subpacakge with pathMajor suffix cmd/go: error loading subpacakge with pathMajor suffix Apr 22, 2019

@thepudds thepudds added the modules label Apr 22, 2019

@thepudds thepudds changed the title cmd/go: error loading subpacakge with pathMajor suffix cmd/go: error loading subpackage with pathMajor suffix Apr 22, 2019

@thepudds

This comment has been minimized.

Copy link

commented Apr 22, 2019

Some possibly related discussion in #30850, #30851.

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