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: go get module versions are inconsistent with pkgsite #52721

Open
rogpeppe opened this issue May 5, 2022 · 3 comments
Open

cmd/go: go get module versions are inconsistent with pkgsite #52721

rogpeppe opened this issue May 5, 2022 · 3 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Unfortunate
Milestone

Comments

@rogpeppe
Copy link
Contributor

rogpeppe commented May 5, 2022

A while ago I made a new repo (github.com/go-quicktest/qt) which was a fork of an older repository (github.com/frankban/quicktest) but a new major version and module path. At some point, the tags from the old repository were accidentally pushed to the new repo, although they have since been removed. None of those old tagged versions are functional in the new repo because the declared module path in all of them does not match the import path of the module.

We have only intentionally published two versions of the new module so far (v0.0.1 and v0.0.2).

Pkgsite only shows those two versions, exactly as we'd hope:

image

However, cmd/go sees some of the old invalid versions too:

$ go list -m -versions github.com/go-quicktest/qt
github.com/go-quicktest/qt v0.0.1 v0.0.2 v1.3.0 v1.7.0 v1.9.0 v1.14.1 v1.14.2

This means that go get github.com/go-quicktest/qt will fail because the "latest" version that it sees is an invalid version.

At this point, we could publish v1.15.0 that retracts the earlier invalid v1 versions, but that's not ideal because we're not quite ready to stabilize the API (and we definitely don't want to move to v2 when there's never been a viable v1).

It would be great if the module cache could avoid caching versions where the import path doesn't match the declared module path or, alternatively, if the go import logic could avoid considering versions that have a mismatch.

AFAICS the main wrinkle here is the replace directive, where it is actually legitimate for a module to declare a path that's not the path that it's found at, but that's an unusual case, and I suspect that people will usually be replacing with an explicitly known version rather than using go get, so maybe it's OK to avoid listing versions with mismatched module paths.

@bcmills
Copy link
Contributor

bcmills commented May 5, 2022

AFAICS the main wrinkle here is the replace directive, where it is actually legitimate for a module to declare a path that's not the path that it's found at

That is correct. But determining that the module path is mismatched requires at least downloading the go.mod file, and go list -versions intentionally doesn't fetch O(N) files when listing N versions found in the repo — in most cases that would be needlessly expensive.

I suggest that you publish a v1.15.0 that retracts the earlier versions and itself, leaving v0.0.1 and v0.0.2 as the earliest non-retracted versions — would that work for your use-case?

@rogpeppe
Copy link
Contributor Author

rogpeppe commented May 5, 2022

Is it really possible to self-retract? That's an interesting idea! I'll give that a go (will it later be possible to publish those same versions again but with different commits?)

But determining that the module path is mismatched requires at least downloading the go.mod file,

I'd imagine that the proxy might cache and make available some of the metadata from the go.mod file (including the declared module path), but from what you've said I guess that isn't the case.

@seankhliao
Copy link
Member

will it later be possible to publish those same versions again but with different commits?

no, sumdb will present a security error

@heschi heschi added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label May 9, 2022
@heschi heschi added this to the Backlog milestone May 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Unfortunate
Projects
None yet
Development

No branches or pull requests

4 participants