merge the core parts of `django-redis` and `django-valkey`?

[amirreza8002]

hi 👋
i'm the maintainer of django-valkey
which is a fork of this project
so there is a lot of shared code between these two

i wanted to propose we merge the common code of them into a core package, and these packages can be kind of like wrapper around it, and only implement server specific logic (importing redis or valkey, lua scripts, etc...)

i should note that, at the moment django-valkey has support for three async clients and one cluster client, plus a few more compressors, which in case of a merge will work for django-redis as well
there is also a few bug fixes in there that would be beneficial here, and some additional unit test for safety.

this might make the maintenance of both packages easier, and allow us to join minds in future developments.

apart from making maintenance and development easier, this will also make creating cache backends for other similar servers easier

let me know what you think ❤️

[amirreza8002]

tldr:
a base package that handles the core parts of caching

so this package and mine and similar can wrap it and work with a unified codebase

[ulgens]

We already discussed in Django's Discord server, but for a paper trail, I'll summarize my take here:

• If a fork is similar enough to django-redis that they can use the common base, it's easier and cheaper to design that other package with a django-redis dependency, instead of creating a new package/approach.
• If a fork has useful features for the upstream, they can be pushed to upstream.
• jazzband is already a dying community and the package is barely maintained. A rewrite of that level doesn't sound feasible or realistic.

there is also a few bug fixes in there that would be beneficial here, and some additional unit test for safety.

Sounds like a perfect opportunity to create PRs to upstream 🎈

this might make the maintenance of both packages easier, and allow us to join minds in future developments.

apart from making maintenance and development easier

These statements miss the cost of the recommended change. If enough effort was given, all forks of Redis could share a common base, but using the already existing django-redis package as that base is still significantly cheaper.

That being said, I'm willing to help with anything that could improve the package. Feel free to ping me for a review of any improvements you mentioned, and I'll do my best to assist with them.

[amirreza8002]

hi
so just as a visual reference, default client will look something like this https://github.com/django-commons/django-valkey/blob/main/django_valkey/client/default.py
similar thing will happen to other parts

django valkey already heavily relies on base classes to implement everything

so in case of this happening, almost everything will be moved to the base package and these packages will only keep:

1. parts where underlying library (redis-py or valkey-py) is used (e.g: connection pool)
2. server specific methods, like lua scripts (_incr method)
3. external API

but, it's up to you to decide
in case of approval i'm ready to take the heavy lifting, tho i'd appreciate all helps

[WisdomPill]

tbh I do not have time for any project of this size and side 100% with @ulgens on everything he said, if the fork has useful bits it would be useful to merge them with the upstream library. That said I am open to supporting valkey inside django-redis. So if you want to work on this project to accomodate yours, please feel free to do that.

[amirreza8002]

hi 👋
i hope i can phrase this right, sorry if i fail

django-redis while being a great library, has limitations
in particular, it lacks the ability to grow

a huge chunk of my time spent working on django-valkey has been to restructure the code so it can accept more development and new features

now i'm not saying it's a perfect, but, it can't go back to being a extension on top of django-redis

the codebase is big, and has a different structure
it heavily relys on base classes, and implements a lot of tools

also it depends on valkey-py instead of redis-py

so i just can't see how it would be moved to django-redis as is

the only way is to heavily refactor django-redis, but i don't see that happening

so i made this suggestion, thought it might be worth concidering

but if the django-redis community doesn't want this, it's fine with me