Fork first-party Redis clients?

It's more of a cultural matter, in giving people a place to migrate not only the non-free implementation but the community which has grown around it. So you can import redict instead of import redis. It's a political move to make redis obsolete and cut Redis Ltd out of the supply chain.

It's more of a cultural matter, in giving people a place to migrate not only the non-free implementation but the community which has grown around it. So you can `import redict` instead of `import redis`. It's a political move to make redis obsolete and cut Redis Ltd out of the supply chain.

Arcaik commented

2024-03-24 17:46:09 +01:00

I agree with you on the cultural and political aspect, but forking can be confusing for users and might even prevent those who do not care too much about SSPL from switching to Redict (“wait, do I need to update all my dependencies too?”).

One argument I see in favour of forking is that at some point Redict and Redis will diverge and might even become incompatible. At that point the question will be whether Redis Ltd will accept patches to official clients to keep them compatible with both projects. I personally doubt that.

I agree with you on the cultural and political aspect, but forking can be confusing for users and might even prevent those who do not care too much about SSPL from switching to Redict (“wait, do I need to update all my dependencies too?”). One argument I see in favour of forking is that at some point Redict and Redis will diverge and might even become incompatible. At that point the question will be whether Redis Ltd will accept patches to official clients to keep them compatible with both projects. I personally doubt that.

ddevault commented

2024-03-24 17:49:04 +01:00

Author

Owner

Well, it's not a priority. We'll get to it in the long tail.

👍 1

ddevault added the

contribution welcome

label

2024-03-24 23:09:22 +01:00

sohail commented

2024-04-16 09:34:47 +02:00

I personally need Python and Go clients.

Afaik, those are not affected by any license change nor governed by the Redis corp. I speculate that they exist in the redis org namespace for reach and/or sponsorships.

> I personally need Python and Go clients. Afaik, those are not affected by any license change nor governed by the Redis corp. I speculate that they exist in the `redis` org namespace for reach and/or sponsorships.

lhinderberger commented

2024-08-10 00:05:19 +02:00

Another approach might be endorsing vendor-neutral / RESP-only clients. Redigo comes to mind for Go (https://github.com/gomodule/redigo).

(Even though it unfortunately does use "redis" as a package name, but the maintainer is thinking about developing a v2, so maybe they can be convinced to change it to something vendor-neutral at that opportunity).

Another approach might be endorsing vendor-neutral / RESP-only clients. Redigo comes to mind for Go (https://github.com/gomodule/redigo). (Even though it unfortunately does use "redis" as a package name, but the maintainer is thinking about developing a v2, so maybe they can be convinced to change it to something vendor-neutral at that opportunity).

mickenordin commented

2025-01-16 14:27:24 +01:00

Owner

At work we now ran in to an issue where redis has implemented new commands (HEXPIRE, HEXPIREAT, HPERSIST, HSET, HDEL) https://redis.io/docs/latest/commands/hexpire/

and these are picked up by clients: https://pkg.go.dev/github.com/redis/go-redis/v9#Client.HExpire which caused an issue for the developers. So either forking clients or in some other way make clear what features are accessible is neccessary.

If we don't fork clients, I think that they may become more and more unusable with redict as time goes on.

At work we now ran in to an issue where redis has implemented new commands (HEXPIRE, HEXPIREAT, HPERSIST, HSET, HDEL) https://redis.io/docs/latest/commands/hexpire/ and these are picked up by clients: https://pkg.go.dev/github.com/redis/go-redis/v9#Client.HExpire which caused an issue for the developers. So either forking clients or in some other way make clear what features are accessible is neccessary. If we don't fork clients, I think that they may become more and more unusable with redict as time goes on.

ddevault commented

2025-01-16 14:28:38 +01:00

Author

Owner

Since you depend on go-redis, would you be open to sponsoring the fork within your org? I also depend on go-redis so I'm down to help out.

mickenordin commented

2025-01-16 14:48:48 +01:00

Owner

I roped in my colleague Magnus @masv3971 who is the go developer with the issue, and he is up for working on this and co-maintain a fork with you. I'll see if I can get him onto irc to discuss about about the way forward :)

👍 1

masv3971 commented

2025-01-16 14:57:39 +01:00

Member

hello everyone! Nice to be here, I would like to help out with the go-redis fork.

einar-hjortdal commented

2025-03-21 10:22:13 +01:00

I've got this one, it is currently the only working client for redis-compatible db in the V language, and it is intended to be redict-first.

I've got [this one](https://github.com/einar-hjortdal/redict), it is currently the only working client for redis-compatible db in the V language, and it is intended to be redict-first.

Rows
Columns

Fork first-party Redis clients? #19