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

[rogpeppe]

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:

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]

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]

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]

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

no, sumdb will present a security error

[matloob]

I don't think there's much we can do here? Please reopen if that's not the case.