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.

Sign up for GitHub

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

Jump to bottom

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

Closed
tomasruud opened this issue Feb 23, 2023 · 7 comments
Closed

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

tomasruud opened this issue Feb 23, 2023 · 7 comments
Assignees
@bcmills
Labels
GoCommand cmd/go modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Milestone
Backlog

Comments

@tomasruud
Copy link

tomasruud commented Feb 23, 2023 •
edited

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 thanm added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. GoCommand cmd/go labels Feb 23, 2023
@thanm
Copy link
Contributor

thanm commented Feb 23, 2023

@golang/tools-team

@bcmills bcmills added this to the Backlog milestone Feb 23, 2023
@bcmills bcmills self-assigned this Feb 23, 2023
@seankhliao seankhliao changed the title go modules: unable to get major versions/sub modules when using vanity urls cmd/go: unable to get major versions/sub modules when using vanity urls Feb 24, 2023
@bcmills
Copy link
Contributor

bcmills commented Mar 16, 2023

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.

@bcmills bcmills added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Mar 16, 2023
@tomasruud
Copy link
Author

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
Copy link
Contributor

bcmills commented Mar 17, 2023

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.

@bcmills bcmills added WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. and removed WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels Mar 17, 2023
@tomasruud
Copy link
Author

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.

@seankhliao seankhliao closed this as not planned Won't fix, can't repro, duplicate, stale Mar 20, 2023
@rcoreilly
Copy link

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
Copy link
Author

@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.

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

@bcmills bcmills

Labels
GoCommand cmd/go modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
5 participants
@bcmills @tomasruud @rcoreilly @seankhliao @thanm