cmd/go: unable to get major versions/sub modules when using vanity urls

[tomasruud]

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

$ go version
go version go1.19.6 darwin/arm64

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
GOHOSTARCH="arm64"
GOHOSTOS="darwin"

What did you do?

I have a small package set up at https://github.com/tomasruud/gvm for reproducing this issue. This package is set up with vanity urls, by using Github pages as hosting. The root of the package has module name tomasruud.github.io/gvm, which is linked up with Github pages, so when you try to get https://tomasruud.github.io/gvm you'll be served an html page with the go-import set to point to the Github repository.

This works fine for major version v0 and v1, but once I try to add a v2 module in my project, go mod seems to be unable to find the tomasruud.github.io/gvm/v2 module. I have added v2 as a submodule by following the documentation, so the code lives in a v2 folder under the root of the project, with its own go.mod file.

The same issue happens with other submodules in the project. I have tried adding a foo module and tagging it accordingly, but go mod seems unable to find this module also.

What did you expect to see?

I would expect go mod to be able to resolve the submodules based on the tags and subfolder from the repository.

What did you see instead?

Instead I'm getting errors like these

$ go get tomasruud.github.io/gvm/v2@v2.0.0
go: tomasruud.github.io/gvm@v2.0.0: invalid version: module contains a go.mod file, so module path must match major version ("tomasruud.github.io/gvm/v2")

[thanm]

@golang/tools-team

[bcmills]

The error message here is not wrong. At the tag v2.0.0 that module's go.mod file declares its path to be module tomasruud.github.io/gvm, not module tomasruud.github.io/gvm/v2 as it would need to be for that major version.

[tomasruud]

But should I have to modify the go.mod at root, wouldn't that break backwards compatibility? The ./v2 contains the actual v2.0.0 code and declares its path accordingly.

[bcmills]

Ah, well there's your problem. The go-import metadata being served for https://tomasruud.github.io/gvm/v2/ is:

<meta name="go-import" content="tomasruud.github.io/gvm/v2 git https://github.com/tomasruud/gvm">

Note that per https://go.dev/ref/mod the first field of the content is “the repository root path, the portion of the module path that corresponds to the repository’s root directory.”

So the go-import metadata is saying that the root of the github.com/tomasruud/gvm repo contains the module tomasruud.github.io/gvm/v2, which isn't the case (that module is in the v2 subdirectory), and so go get is reporting that that's not the case.

[tomasruud]

Thank you! Seems like changing the first part of the content field to align with the name of the root module did the trick. So I guess that was the issue all along. Perhaps the documentation could benefit from some examples around this matter, as it wasn't entirely clear that you had to do it this way, just by reading it.

[rcoreilly]

Sorry to post in a closed issue here, but it appears that, despite the name fix above, it is still not possible to combine vanity imports and submodules?

e.g.,:

go get tomasruud.github.io/gvm/foo@latest
go: tomasruud.github.io/gvm/foo@latest (v1.0.0) requires tomasruud.github.io/gvm/foo@v1.0.0: parsing go.mod:
	module declares its path as: tomasruud.github.io/gvm
	        but was required as: tomasruud.github.io/gvm/foo

This is with go version 1.21.0

Is it prohibitively difficult to fix this limitation?

[tomasruud]

@rcoreilly I think this should be working, at least I tried to add a new tag now for the foo package (v1.1.0), and if you go get it, it should work as intended. Might be you have to clean your modcache before doing it, as it might not be able to pick up the latest version automatically.