Skip to content

Unable to replicate retractions for v2+ modules #166

@mattdowdell

Description

@mattdowdell

bingo version output: v0.10

go version output: go version go1.26.0 darwin/arm64

What happened:
I tried to install kubebuilder:

$ bingo get sigs.k8s.io/kubebuilder/v4@v4.13.0
Error: get: v4.mod: getting sigs.k8s.io/kubebuilder/v4@v4.13.0: version "v4.10.0" invalid: should be v4.10.0+incompatible (or module _/v4)
# usage dump trimmed for brevity

What you expected to happen:
I should be able to install kubebuilder

How to reproduce it (as minimally and precisely as possible):
Running bingo get sigs.k8s.io/kubebuilder/v4@v4.13.0 reproduces consistently for me.

Logs (use bingo get -v <thing you do> for verbose output):

$ bingo get sigs.k8s.io/kubebuilder/v4@v4.13.0 -v
getting target sigs.k8s.io/kubebuilder/v4@v4.13.0 (module  )
exec 'go mod init -modfile=/Users/mdowdell/repos/bingo/.bingo/v4-e.tmp.mod _'
exec 'go get -modfile=/Users/mdowdell/repos/bingo/.bingo/v4-e.tmp.mod -d sigs.k8s.io/kubebuilder/v4@v4.13.0'
exec 'go env GOPATH'
exec 'go mod init -modfile=/Users/mdowdell/repos/bingo/.bingo/v4.tmp.mod _'
Error: get: v4.mod: getting sigs.k8s.io/kubebuilder/v4@v4.13.0: version "v4.10.0" invalid: should be v4.10.0+incompatible (or module _/v4)
# usage dump trimmed for brevity

Anything else we need to know:
There are 2 problems here, one easily fixed, another likely more invasive.

The first is the interpretation of the tool name: currently v4. This is attributable to the conditional in https://github.com/bwplotka/bingo/blob/v0.10.0/get.go#L66, e.g.

if pkgSplit := strings.Split(pkgPath, "/"); len(pkgSplit) > 3 && goModVersionRegexp.MatchString(name) {

3 is the problem. For a package such as github.com/example/whatever/v2 we have 4 elements in pkgSplit. If using vanity URLs, and a main.go in the root of the repo, we can end up with something like example.com/whatever/v2. Changing 3 -> 2, or > -> >= will fix that particular problem. I suspect that's just a minor oversight.

The next problem is potentially more complex. The error itself comes from https://github.com/bwplotka/bingo/blob/v0.10.0/pkg/mod/mod.go#L298, e.g.

// VersionInterval: {Low: v4.10.0, High: v4.10.0}
// Rationale: invalid filename causes go get/install failure (#5211)
if err := mf.m.AddRetract(d.VersionInterval, d.Rationale); err != nil {

The actual problem is what's in mf.m, which is of type golang.org/x/mod/modfile.File. Or more specifically, what's in mf.m.Module.Mod.Path which is set to _ as the module name for all*.mod files managed by bingo. The problem is that AddRetract calls checkCanonicalVersion as a quick bit of validation and chokes on the fact that we've passed in v4.10.0 but the module path does not end in /v4.

The fix here is probably to adjust the module name bingo uses to something that aligns with the versioning Go expects, e.g. _/v2 for a module named with example.com/whatever/v2. I'm not entirely sure if that will break on modules that are not using the module versioning conventions, but I suspect they're also not using retractions and so we might be ok?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions