go get -u -t ./... doesn't get the latest version of this module

[dcormier]

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

[dcormier]

CC @bcmills, maybe, since he was involved with getting #440 squared away.

[bcmills]

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.

[stevenh]

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.

[dcormier]

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.

[stevenh]

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

[dcormier]

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.

[stevenh]

Since this isn't something that this package can do anything about, are you happy for me to close?

[dcormier]

I still don't know that it'll work right if/once this package is updated. I'm working on it.

[stevenh]

Ok will keep open for now, fingers crossed.

[bcmills]

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.)

[dcormier]

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.