-
Notifications
You must be signed in to change notification settings - Fork 38
Description
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 brevityWhat 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 brevityAnything 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?