cmd/go: go get module versions are inconsistent with pkgsite #52721
Labels
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Unfortunate
Milestone
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
andv0.0.2
).Pkgsite only shows those two versions, exactly as we'd hope:
However,
cmd/go
sees some of the old invalid versions too: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 invalidv1
versions, but that's not ideal because we're not quite ready to stabilize the API (and we definitely don't want to move tov2
when there's never been a viablev1
).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 usinggo get
, so maybe it's OK to avoid listing versions with mismatched module paths.The text was updated successfully, but these errors were encountered: