[QUESTION] How do we want to handle redis-py?

[daniel-house]

Options:

• Completely excise all mention of it and pretend it doesn't exist.
• Mention it, say how long we will support it (e.g., until it gets changed), and warn against becoming dependent on it.
• Replace it with something else.
• Clone it and rebrand it to yield valkey-py.
• Something else?

Current status:

The command

find . -type f -name \* -exec grep -il redis-py {} \;

reports that the string redis-py appears in these files of the https://github.com/redis/redis-doc repo:

clients/python/github.com/groove-x/gxredis.json
clients/python/github.com/Grokzen/redis-py-cluster.json
clients/python/github.com/redis/redis-py.json
README.md
wordlist
docs/connect/clients/python.md

In the https://github.com/valkey-io/valkey-doc repo it appears in these files:

clients/python/github.com/groove-x/gxredis.json
clients/python/github.com/Grokzen/redis-py-cluster.json
clients/python/github.com/redis/redis-py.json
wordlist
docs/connect/clients/python.md

In the Valkey version of README.md, it was replaced with placeholderkv-py in two places.

[mnislam01]

Clone it and rebrand it to yield valkey-py

[zuiderkwast]

I'm not sure we want to maintain clones of all clients. We have other things to do. :)

We are redis-7.2 compatible so all redis clients are valkey clients for now. The path needs to match where the client's home is though, so if we wrote "placeholderkv" somewhere, we need to change back to "github.com/redis/redis-py".

In the README, it's just an example of how to add clients to the docs. In https://codeberg.org/redict/redict-doc they just removed the example.

[madolson]

I think we should, in the fullness of time, aim to maintain forks of the clients. The Redis client ecosystem is all over the place, and one of the ways we can make Valkey better is to have more "official" clients. Python is likely a good one to do first, especially if we want to start using it for testing.

[yangbodong22011]

As a Jedis Reviewer, especially in the Java ecosystem, I personally don’t think forking the client would be a wise choice, ~~because unless we do a very thorough renaming and package path modification (such as renaming redis.clients.jedis.Jedis is io.valkey.ValkeyXX), otherwise when the user relies on jedis or valkey-jedis at the same time, a class conflict will occur. Even if the renaming and publishing are completed, users will still need to make a lot of adaptations, that is, from Jedis jedis = new Jedis() to ValkeyXX valkey = new ValkeyXX(). This is a very large code change.~~

EDIT： The above statement is wrong. Java distinguishes classes according to paths. Classes with the same name are allowed under different paths. For example, redis.clients.Jedis and io.valkey.Jedis can coexist.

[kamikaze]

Clone it and rebrand it to yield valkey-py.

[zuiderkwast]

@kamikaze Are you willing to be an active maintainer of it?

[PingXie]

I agree with @madolson's vision that we need official Valkey clients but I would side with @yangbodong22011 on the tactics. Cloning and forking existing Redis clients will easily end up boiling the ocean. I don't think we should take that approach. I have been advocating this offline but also wanted to share my vision here on how we could evolve the Valkey client ecosystem. I think it will be great if we could team up with the GLIDE maintainers and explore the opportunity of making GLIDE a native Valkey client. I think GLIDE's approach of "write once (in RUST) and run everywhere (through language binding)" would help us quickly close the gap in the client ecosystem. But again, I am not suggesting we clone GLIDE under Valkey. There should still be one GLIDE project.

[bmuessig]

I doubt it would make sense to fork every single Redis client. That would be an unmaintainable nightmare without any benefit. Valkey being compatible by design with Redis should be enough.

[madolson]

I think it will be great if we could team up with the GLIDE maintainers and explore the opportunity of making GLIDE a native Valkey client. I think GLIDE's approach of "write once (in RUST) and run everywhere (through language binding)" would help us quickly close the gap in the client ecosystem. But again, I am not suggesting we clone GLIDE under Valkey. There should still be one GLIDE project.

So GLIDE is an AWS client, and they are very aligned with the idea of being the official client for Valkey. I've talked with the folks, and they would be open to to discussing moving it officially under valkey. We have more problems to deal with though:

1. Their is a huge install base of Redis that is not using glide, that we would like to move to Valkey if they don't like the license change. Asking them to move to a new client that is quite different is not a small effort.
2. GLIDE isn't GA, and has very little production usage. I'm really hesitant to lean into a client that has so little proven ground around it. There could be structural problems that prevents widespread adoption we still haven't seen.

Tactically we need a short term and long term perspective. The long term might be glide. We also have to deal with the fact that Redis will likely no longer accept features that are just for Valkey. If we introduce a new API, let's say empty sets since it's on my mind, which has new APIs, what do we do about that? It could even be worse, they might explicitly introduce APIs that try to detect it's Valkey and prevent access. Redis only has like 6 official clients (I tried to find them but their website is so broken I couldn't find them, but it's like go, ioredis, ruiredis, jedis, lettuce, redis-py, and probably some more). I think we should consider being ready to fork those at a moments notice as well as reaching out to other client developers to make sure they don't give their clients to Redis.

[zuiderkwast]

Reaching out to all non-official client authors would be good. We can ask them to update their info that they support valkey and add valkey to their ci. There are many such clients. Supporting both would just be good for them, don't you think?

[PingXie]

Good to know that GLIDE is joining Valkey :)

Here is my view of the short/medium/long term strategies

• short-term

Let's not break any clients. This is also why I'd like to delay the discussion of removing any compat support, which should not be a time bound decision.

• medium-term

As @zuiderkwast mentioned above, work with the existing Redis clients to bring Valkey support there (as opposed to forking them here). I am calling this medium term because I expect it will take us a while to get there; not because we should delay the outreach.

• long-term

GLIDE. The timeline is also about the "delivery date" not the starting date.

[yangbodong22011]

From a user perspective, migrating the client is indeed a relatively large task:

1. The code needs to be modified.
2. Various tests: compatibility, performance, etc.

For the sake of customer continuity, it seems that forking the client has to be considered. If allowed, I would like to fork a client first (such as Jedis).

[zuiderkwast]

If allowed, I would like to fork a client first (such as Jedis).

I would say yes, if you are ready to maintain it long-term or find others who can help maintain it. The core team members will probably not have time to maintain forked clients.

[yangbodong22011]

List some Redis clients held by Redis Inc and other open source Redis clients. Clients willing to support valkey are also welcome to comment under this post:

Language	Redis Inc	OSS
Java	Jedis, Lettuce	Redisson(commercial)
Node.js	node-redis, ioredis
Go	go-redis, rueidis	redigo
Python	redis-py
C	hiredis
Ruby	redis-rb
Erlang		eredis, ered

[yangbodong22011]

If allowed, I would like to fork a client first (such as Jedis).

I would say yes, if you are ready to maintain it long-term or find others who can help maintain it. The core team members will probably not have time to maintain forked clients.

Yes, I am ready to maintain and add a new feature to valkey-jedis(Name to be determined). If the fork clients strategy will be approved by the @valkey-io/core-team , the next step is to fork Jedis under the Valkey organization, and I will start working.

[daniel-house]

We also have to deal with the fact that Redis will likely no longer accept features that are just for Valkey.

They will probably accept any features that threaten to lure people to Valkey.

they might explicitly introduce APIs that try to detect it's Valkey and prevent access.

If they don't do this, they are incompetent.

It should be expected that they will attempt to decommodify the protocol. They will be looking for ways to extend the protocol so that at best we will be constantly working to remain compatible with them and at worst we will be legally blocked from remaining compatible. The good news is, it didn't work for Microsoft so it probably won't work for Redis.

[PingXie]

Yes, I am ready to maintain and add a new feature to valkey-jedis(Name to be determined). If the fork clients strategy will be approved by the @valkey-io/core-team , the next step is to fork Jedis under the Valkey organization, and I will start working.

I wouldn't suggest valkey-jedis for the branding reason. I would also suggest not starting this fork under the Valkey project, yet.

It should be expected that they will attempt to decommodify the protocol. They will be looking for ways to extend the protocol so that at best we will be constantly working to remain compatible with them and at worst we will be legally blocked from remaining compatible.

Although I share the exact same sentiment, I think this will take quite a while for them to get there. In the meanwhile, the best we can do IMO is still maintaining full compat with these clients.

[daniel-house]

The Redis protocol is old enough and popular enough - maybe it deserves to move from being a de-facto standard to being an ISO standard.

[PingXie]

I love this idea. One downside is that any change will have to through a huge committee but on a second thought Redis never had the freedom to unilaterally change the protocol anyways, given the diverse client ecosystem.

[yangbodong22011]

In addition to maintenance, I plan to provide the following functionality for valkey-jedis(Name to be determined):

• Support valkey new api (such as ValkeyHash and ValkeyJSON)
• Support asynchronous linking
• Introducing a thread pool to improve the performance of ClusterPipeline
• Reduce the number of JedisPool connections in cluster mode
• etc

While Fork Clients are not "elegant", I think they are advantageous both for users and for early valkey, and I don't like to talk about anything without users. I agree we have a big vision (GLIDE), but before we get there, we need a path (Fork Clients).

[soloestoy]

Didn't read the entire content. My opinion is that, whether we fork or redevelop, we should have our own clients to better control the ecosystem's development.

[PingXie]

I see some major decisions for @valkey-io/core-team.

1. forking a client under Valkey. Forking itself is not but forking under Valkey IMO is a major decision
2. why Jedis? why not Lettue? why Jave? why not Go?
3. naming. I don't like keeping Jedis. There can be a way to respect history but also start something new. Also there could be trademark risks now that Jedis is owned by Redis. The same concern applies to other clients as well.

Additionally, I think we should have a straight story on how we plan to differentiate a GLIDE based Java client in the future vs a Jedis fork, if we plan to support both in the long run. If not, what is the high level exit strategy (for whichever one to be exited).

[yangbodong22011]

Jedis is a beginning (because I am familiar with it and deeply involved in it before), which does not mean that we will not consider other Forks (Lettuce, Go, or Python), but we have not encountered willing maintainers (except for me).If more and more users are proposing requirements, or if these requirements are what Valkey needs to do, I think we need to consider fork more. I believe that with the power of open source, there will be more people to maintain and modify, and refactor more fork clients.

Additionally, I think we should have a straight story on how we plan to differentiate a GLIDE based Java client in the future vs a Jedis fork, if we plan to support both in the long run. If not, what is the high level exit strategy (for whichever one to be exited).

I think there is no problem with having two types of clients for a long time. In fact, Redis even has more, such as Jedis, Lettuce, and Redisson, depending on the choice of maintainers and users, rather than what Valkey needs to decide. Of course, Valkey can regularly remove inactive clients from Valkey organization.

[zuiderkwast]

• We probably need one client for each major language. Java is certainly one of them (whether you like it or not). It seems more efficient to focus on one (the best one) for each language, but ultimately it is up to the person who wants to maintain it.
• Name is up to client maintainer imho.
• If we host it under Valkey or not is not extremely important. If the client is named something related to valkey and we recommend it in out website, it doesn't matter much where it is hosted. I think it's best to start somewhere else and when it is ready, it can be moved to the valkey org.
• We have a lot of client maintainers in an old slack channel called #clients. Many of them, even for some clients which are under github/redis, like hiredis and rueidis, are not Redis Labs employees. I can imagine some of them are interested in supporting Valkey.

[zuiderkwast]

A Java client can be called Jackey (java valkey) and have Jackie Chan as the logo.

[daniel-house]

I would be much more worried about trademark enforcement from Jackie Chan than anything Redis Inc might do.

[yangbodong22011]

ioredis -> iovalkey: https://github.com/valkey-io/valkey/issues/329

[PingXie]

After some more offline discussion, I can see more upside in forking these clients since a lot of features we are planning to work on would require client support. I am onboard with forking existing high quality OSS clients under Valkey.

I don't know about "Jackey" though :)

[yangbodong22011]

ok, before we continue, I have some questions to confirm (I will write a document later for the rest of the client maintainers to refer to):

1. About trademarks

• Is the word Redis allowed to appear in Fork Clients?
• if I Fork Jedis, do I allow the word Jedis to appear?

2. About the warehouse

• The repository will be placed under valkey, who is responsible for performing the fork operation.

I don't know about "Jackey" though :)

Is the suggested client name @zuiderkwast mentioned above, I like it, but it doesn't exist yet.

[soloestoy]

I think we have a clear direction. For major languages, we need to have our own clients. I suggest starting with Java :)

@valkey-io/core-team Let's have a vote on this, fork Jedis and rename it to Jackey. Give your 👍 or 👎 please.