`go get -u -t ./...` doesn't get the latest version of this module
dcormier opened this issue · 11 comments
Despite the work for #366/#440, go still tries to get v2.0.0+incompatible. This is with go1.19.2 darwin/amd64.
> go get -u -t ./...
go: warning: github.com/gomodule/redigo@v2.0.0+incompatible: retracted by module author: Old development version not maintained or published.
go: to switch to the latest unretracted version, run:
go get github.com/gomodule/redigo@latest
OK, fine. I'll run that.
> go get github.com/gomodule/redigo@latest
go: downgraded github.com/go-redsync/redsync v1.4.2 => v1.0.1
go: downgraded github.com/gomodule/redigo v2.0.0+incompatible => v1.8.9
Alright, it's got the correct version of redigo, now. Good. I don't understand why go wasn't smart enough to do that in the first place, though.
But the next time I try to update my dependencies, I get the same thing I originally got:
go get -u -t ./...
go: warning: github.com/gomodule/redigo@v2.0.0+incompatible: retracted by module author: Old development version not maintained or published.
go: to switch to the latest unretracted version, run:
go get github.com/gomodule/redigo@latest
It seems to me that the difficulty here is that github.com/go-redsync/redsync v1.4.2 is the latest version of that module (they appear to have dropped maintenance on v1 in 2020) and has a requirement on redigo v2.0.0+incompatible.
So, one solution would be to find a way to drop your project's dependency on github.com/go-redsync/redsync (perhaps by migrating to github.com/go-redsync/redsync/v4).
Another would be to request that the owners of redsync issue a v1.4.3 changing their dependency on redigo from v2.0.0+incompatible to v0.0.0-20180314223443-9c11da706d9b, which is another name for the same commit. (Both are valid because there is no go.mod file at that revision to give a canonical module path).
A third would be to add exclude github.com/gomodule/redigo v2.0.0+incompatible to your go.mod file, pruning the spurious dependency out of your module graph.
To clarify something, redigo has no dependency on redsync. I believe it's the other way round
> go get github.com/gomodule/redigo@latest
go: downgraded github.com/go-redsync/redsync v1.4.2 => v1.0.1
go: downgraded github.com/gomodule/redigo v2.0.0+incompatible => v1.8.9
As bcmills states if you update your project to use github.com/go-redsync/redsync/v4 then I believe go get -u will just work.
My project does depend on github.com/go-redsync/redsync/v4. It's a dependency that uses github.com/go-redsync/redsync.
I hate golang's dependency management so much.
To be fair its come a long way and this is really down to unmaintained code.
I would try to see if your dependency really needs the original or if it could be updated.
Try this and see if it works:
go mod edit -replace github.com/go-redsync/redsync=github.com/go-redsync/redsync/v4
Sadly, it still needs the old version. The Pool interface chaged in v3. In v2 and prior, Pool.Get() returned a github.com/gomodule/redigo/redis.Conn, which you can call .Do() on and execute an arbitrary redis command.
The Pool interface from v3 on returns a github.com/go-redsync/redsync/v4/redis.Conn, which only exposes helper methods and not a method for executing arbitrary redis commands (other than through scripting).
The dependency in question is doing something that it can't do with the existing methods on github.com/go-redsync/redsync/v4/redis.Conn, unless it changes to run a script just to run a single command.
I'll open an issue asking for the Conn interface to expose something like the .Do() method for arbitrary redis commands. It would be simple, but it would require a incrementing the major version since it breaks compatibility.
Since this isn't something that this package can do anything about, are you happy for me to close?
I still don't know that it'll work right if/once this package is updated. I'm working on it.
Ok will keep open for now, fingers crossed.
It would be simple, but it would require a incrementing the major version since it breaks compatibility.
A similar, non-breaking change would be to define a the method in a separate interface and promise that all Conn instances returned by the relevant Pool can be type-asserted to that interface.
(FWIW, that sort of incompatibility is exactly why the advice in https://go.dev/wiki/CodeReviewComments#interfaces is to return concrete types instead of interfaces.)
I still don't know that it'll work right if/once this package is updated. I'm working on it.
Got all the dependencies updated. Thank you.