[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: #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 :)

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

[kamikaze]

yet another fork which eventally realized that forking is not enough

[soloestoy]

@kamikaze this is a core team vote, and we hope to conduct open voting, currently done through the use of 👍 or 👎 in comments. Perhaps in the future, we may have better methods. So please do not use 👍 or 👎 now, you can use other emojis instead :)

BTW, forking doesn't means the end. Forking and writing a new one can be done in parallel.

[PingXie]

@soloestoy, I think we should separate the two decisions

1. whether to fork?
2. what should the fork be called?

For 1) my vote is yes (and under Valkey). For 2), I am not a fan of Jackey (nor Jackie :-)) but I don't have a better name.

@yangbodong22011, I would say "jedis" should definitely not appear in the repo name. ideally, the jar name should not contain jedis as well. unfortunately, dropping/renaming "jedis" in the public interfaces such as class names would be harder to deal with for the existing jedis users IMO as this would require code change in their applications. maybe we could consider exposing two sets of interfaces, a native "XXX" interface, and a Jedis interface that wraps around the native ones?

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

I think you can feel free to fork it under your own project while the logistics are being worked out. we should finalize on the sub-project governance first before moving clients into valkey as @madolson called out in #329

[yangbodong22011]

I've created a Jedis fork here https://github.com/valkey-io/jackey and the first compatible version will be released soon.

[zuiderkwast]

Haha! Regarding Jackey, I think the "likelihood of confusion" with the actor is zero so it's not a trademark issue. There might be copyright on the photo though, but there may be other photos on wikipedia, etc. with a usable license. I read Jackie Chan is involved in politics now and of course it can be controversial. Anyway, I want to encourage everyone who wants to maintain a fork and name it whatever they want.

On the other hand, we may not need to split the whole community. When we add new Valkey-specific features, I'm sure many clients will want to add them anyway. And as long as most of the users are running Redis 6, I don't think they want to abandon Redis.

Here is double-branding in progress: "Prometheus ValKey & Redis Metrics Exporter" oliver006/redis_exporter#899 (PR by the maintainer himself)

[PingXie]

everyone who wants to maintain a fork and name it whatever they want.

Sure maintainers get to choose the name but there is a nuance here. Valkey will not accept a client under its umbrella as a sub project if the name chose is not aligned with the Valkey vision/value/etc. This is by no means a major issue but just wanted to call it out for awareness

[soloestoy]

OK, let's vote for the first one @valkey-io/core-team , fork Jedis under Valkey. Give your 👍 or 👎 please.

[enjoy-binbin]

i think @yangbodong22011 will be a good maintainer 👍

[zuiderkwast]

Related: We have a Valkey Go client with a maintainer ready to take off. It's a fork of rueidis by the original creator. See https://github.com/orgs/valkey-io/discussions/335#discussioncomment-9167466

[madolson]

We had a meeting with the maintainers this morning (notes to be published shortly) and we were all in broad agreement that we should start proactively forking clients. The consensus is we should talk one client per language as the "suggested" implementation". If there is interest in another client, we'd ask for the time being it be supported by the community.

[aiven-sal]

I would be happy to help maintaining a redis-py fork under Valkey. My employer uses it.

[mkmkme]

Hello! I would like to handle hiredis and hiredis-py, if these libraries are not yet taken by another person.

[zuiderkwast]

Hiredis is used by valkey-cli and valkey-benchmark. @michael-grunder is the maintainer of hiredis. I suppose he may want to be involved.

[michael-grunder]

I'm more than happy to keep maintining a valley fork of hiredis but the more the merrier.

If someone in the valley org forks hiredis into valkey-io/hivalkey we can get started on a roadmap, etc.

[mkmkme]

Sure, I'll be glad to help!
In addition to that or as an alternative, I can join @aiven-sal with redis-py as we're coworkers :)

[hwware]

Honestly said, I think hiredis ->hivalkey is not a good name, because how everyone know it is a C client?

[zuiderkwast]

valkey-c, valkeyc?

If we call it valkey-c, what will you call the fork of hiredis-py? valkey-c-py? 😆

[michael-grunder]

It's a good point. I just figured hiredis -> hivalkey but that's because I'm boring. Also as everyone knows, naming things is one of only two hard problems in CS.

MySQL's C library is libmysqlclient so I suppose we could go with something similar like libvalkeyclient. or just libvalkey.

[madolson]

@mkmkme and @aiven-sal, if either of you two want to create a fork of redis-py (called valkey-py), I'll give you permissions to move it under the valkey org. Right now we are just a bit busy with other stuff, so would appreciate if you could just make that happen.

[aiven-sal]

I can do it! Thanks a lot!

[zuiderkwast]

Let's continue hiredis discussions in #511.

[aiven-sal]

@madolson I think we are ready to move the repo (there is still some more work to do, but it's forked)
https://github.com/aiven-sal/valkey-py

[madolson]

@aiven-sal I've invited you to the valkey-io organization, once you accept you should have the permissions to move it.

[aiven-sal]

Thank you very much! I moved it https://github.com/valkey-io/valkey-py

[madolson]

Ok, I think we can close this now that the repository has been moved.