django-cachex 0.4.2__tar.gz → 0.5.0__tar.gz

{django_cachex-0.4.2 → django_cachex-0.5.0}/.gitignore

@@ -35,8 +35,3 @@ CLAUDE.md
 site/
 *.sqlite3
 docs/superpowers/
-
-# Rust build artifacts
-target/
-django_cachex/adapters/_redis_rs*.so
-crates/django-cachex-redis-rs/python/django_cachex/adapters/_redis_rs*.so

{django_cachex-0.4.2 → django_cachex-0.5.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: django-cachex
-Version: 0.4.2
+Version: 0.5.0
 Summary: Full featured Valkey and Redis cache backend for Django
 Project-URL: Homepage, https://github.com/oliverhaas/django-cachex
 Project-URL: Documentation, https://oliverhaas.github.io/django-cachex/
@@ -43,8 +43,6 @@ Provides-Extra: ormsgpack
 Requires-Dist: ormsgpack>=1.10.0; extra == 'ormsgpack'
 Provides-Extra: redis-py
 Requires-Dist: redis<9,>=6; extra == 'redis-py'
-Provides-Extra: redis-rs
-Requires-Dist: django-cachex-redis-rs==0.4.2; extra == 'redis-rs'
 Provides-Extra: valkey-glide
 Requires-Dist: valkey-glide-sync<3,>=2.3; extra == 'valkey-glide'
 Requires-Dist: valkey-glide<3,>=2.3; extra == 'valkey-glide'
@@ -90,7 +88,6 @@ CACHES = {
 - Cache stampede prevention (TTL-based XFetch).
 - Two composite backends: `StreamCache` (cross-pod stream-synchronized in-memory cache) and `TieredCache` (L1/L2 with TTL propagation).
 - Django `LocMemCache` and `DatabaseCache` extensions with the same data-structure ops and admin support.
-- Optional Rust I/O driver (PyO3 + tokio + redis-rs) under the same `RespCache` API. Free-threaded CPython (3.14t) supported. Experimental.
 - Optional `valkey-glide` adapter: Valkey's official Rust-cored client, exposed as `ValkeyGlideCache`. Experimental.
 - Django admin UI for browsing keys, inspecting values, editing, and flushing. See below.
 
@@ -132,17 +129,9 @@ Full documentation at [oliverhaas.github.io/django-cachex](https://oliverhaas.gi
 - Valkey 7.0+ or Redis 6.0+ on the server (the admin's compare-and-swap
   edits use `SET ... KEEPTTL`, which lands in Redis 6.0)
 
-The Rust I/O driver is optional and experimental: interfaces and
+The `valkey-glide` adapter is optional and experimental: interfaces and
 behavior may still change, and it has seen less production testing than
-the redis-py/valkey-py paths. To opt in, install with the `redis-rs`
-extra (`pip install django-cachex[redis-rs]`); this pulls in the
-`django-cachex-redis-rs` companion package. Prebuilt wheels are published
-for Linux x86_64, Linux aarch64, macOS arm64, and Windows amd64, on
-both cp314 and cp314t (free-threaded). Without the extra, the
-`RedisRsCache` backends are unavailable but everything else works.
-
-The `valkey-glide` adapter is also optional and experimental, with the
-same caveats. Install with the `valkey-glide` extra
+the redis-py/valkey-py paths. Install with the `valkey-glide` extra
 (`pip install django-cachex[valkey-glide]`) to enable
 `ValkeyGlideCache`; it pulls in `valkey-glide-sync` and `valkey-glide`,
 the official Rust-cored Valkey client. cp314 GIL only; no free-threaded
@@ -154,7 +143,7 @@ client).
 
 This project started from [django-redis](https://github.com/jazzband/django-redis) and Django's official [Redis cache backend](https://docs.djangoproject.com/en/stable/topics/cache/#redis). Some serializer and compressor utility code is derived from django-redis, licensed under BSD-3-Clause. The admin UI was inspired by [django-redisboard](https://github.com/ionelmc/django-redisboard).
 
-The Rust I/O driver and async bridge are heavily inspired by, and in places directly adapted from, [django-vcache](https://gitlab.com/glitchtip/django-vcache) (MIT, by David Burke / GlitchTip). The fork-safe tokio runtime, the `RedisRsAwaitable` deferred-loop-binding pattern, and the multiplexed-connection design all originate there.
+The ASGI benchmark follows the shape of [django-vcache](https://gitlab.com/glitchtip/django-vcache)'s `bench_compare.py` (MIT, by David Burke / GlitchTip), so the numbers are directly comparable.
 
 I also want to mention [django-valkey](https://github.com/django-commons/django-valkey) and [dj-cache-panel](https://github.com/yassi/dj-cache-panel), which I never really used, but are newer and interesting efforts of similar goals as this package has.
 

{django_cachex-0.4.2 → django_cachex-0.5.0}/README.md

@@ -36,7 +36,6 @@ CACHES = {
 - Cache stampede prevention (TTL-based XFetch).
 - Two composite backends: `StreamCache` (cross-pod stream-synchronized in-memory cache) and `TieredCache` (L1/L2 with TTL propagation).
 - Django `LocMemCache` and `DatabaseCache` extensions with the same data-structure ops and admin support.
-- Optional Rust I/O driver (PyO3 + tokio + redis-rs) under the same `RespCache` API. Free-threaded CPython (3.14t) supported. Experimental.
 - Optional `valkey-glide` adapter: Valkey's official Rust-cored client, exposed as `ValkeyGlideCache`. Experimental.
 - Django admin UI for browsing keys, inspecting values, editing, and flushing. See below.
 
@@ -78,17 +77,9 @@ Full documentation at [oliverhaas.github.io/django-cachex](https://oliverhaas.gi
 - Valkey 7.0+ or Redis 6.0+ on the server (the admin's compare-and-swap
   edits use `SET ... KEEPTTL`, which lands in Redis 6.0)
 
-The Rust I/O driver is optional and experimental: interfaces and
+The `valkey-glide` adapter is optional and experimental: interfaces and
 behavior may still change, and it has seen less production testing than
-the redis-py/valkey-py paths. To opt in, install with the `redis-rs`
-extra (`pip install django-cachex[redis-rs]`); this pulls in the
-`django-cachex-redis-rs` companion package. Prebuilt wheels are published
-for Linux x86_64, Linux aarch64, macOS arm64, and Windows amd64, on
-both cp314 and cp314t (free-threaded). Without the extra, the
-`RedisRsCache` backends are unavailable but everything else works.
-
-The `valkey-glide` adapter is also optional and experimental, with the
-same caveats. Install with the `valkey-glide` extra
+the redis-py/valkey-py paths. Install with the `valkey-glide` extra
 (`pip install django-cachex[valkey-glide]`) to enable
 `ValkeyGlideCache`; it pulls in `valkey-glide-sync` and `valkey-glide`,
 the official Rust-cored Valkey client. cp314 GIL only; no free-threaded
@@ -100,7 +91,7 @@ client).
 
 This project started from [django-redis](https://github.com/jazzband/django-redis) and Django's official [Redis cache backend](https://docs.djangoproject.com/en/stable/topics/cache/#redis). Some serializer and compressor utility code is derived from django-redis, licensed under BSD-3-Clause. The admin UI was inspired by [django-redisboard](https://github.com/ionelmc/django-redisboard).
 
-The Rust I/O driver and async bridge are heavily inspired by, and in places directly adapted from, [django-vcache](https://gitlab.com/glitchtip/django-vcache) (MIT, by David Burke / GlitchTip). The fork-safe tokio runtime, the `RedisRsAwaitable` deferred-loop-binding pattern, and the multiplexed-connection design all originate there.
+The ASGI benchmark follows the shape of [django-vcache](https://gitlab.com/glitchtip/django-vcache)'s `bench_compare.py` (MIT, by David Burke / GlitchTip), so the numbers are directly comparable.
 
 I also want to mention [django-valkey](https://github.com/django-commons/django-valkey) and [dj-cache-panel](https://github.com/yassi/dj-cache-panel), which I never really used, but are newer and interesting efforts of similar goals as this package has.
 

{django_cachex-0.4.2 → django_cachex-0.5.0}/benchmarks/README.md

@@ -15,16 +15,15 @@ depends on letting workloads run).
 - `redis-py+hiredis`: C parser
 - `valkey-py`: pure-Python parser
 - `valkey-py+libvalkey`: C parser
-- `redis-rs`: our Rust extension adapter (PyO3 bindings around the
-  `redis-rs` crate, multiplexed Tokio transport)
-- `valkey-glide`: `valkey/valkey-glide` Python wheels (also Rust-cored,
-  but with a thread-pool transport instead of multiplexed). Only available
-  on cp314 GIL. No cp314t (free-threaded) wheels yet.
+- `valkey-glide`: `valkey/valkey-glide` Python wheels, Rust-cored with a
+  thread-pool transport. Only available on cp314 GIL. No cp314t
+  (free-threaded) wheels yet.
 - `django (builtin)`: Django's official built-in `django.core.cache.backends.redis.RedisCache`
   (since 4.0). Not the third-party `jazzband/django-redis` package, which is
   unrelated. Included as an external reference point.
 
-**Serializers** (with `redis-rs` adapter, since adapter overhead is smallest there):
+**Serializers** (with the `valkey-py+libvalkey` adapter, the fastest one that
+is always installed):
 
 - `pickle`: stdlib default
 - `json`: Django's `DjangoJSONEncoder`
@@ -32,7 +31,7 @@ depends on letting workloads run).
 - `orjson`: Rust-backed JSON
 - `ormsgpack`: Rust-backed MessagePack
 
-**Compressors** get two views, both with `redis-rs` + `pickle`:
+**Compressors** get two views, both with `valkey-py+libvalkey` + `pickle`:
 
 - *Macro* (`test_compressors_macro`): end-to-end Django cache ops on a
   ~14 KiB queryset-shaped payload. Captures the cost of compress/decompress
@@ -128,7 +127,7 @@ uv run pytest benchmarks/test_throughput.py::test_adapters_async_concurrent -c b
 uv run pytest benchmarks/test_throughput.py::test_adapters_asgi             -c benchmarks/pytest.ini
 
 # A single config
-uv run pytest 'benchmarks/test_throughput.py::test_adapters_sync[redis-rs]' -c benchmarks/pytest.ini
+uv run pytest 'benchmarks/test_throughput.py::test_adapters_sync[valkey-glide]' -c benchmarks/pytest.ini
 ```
 
 `test_compressors_micro` is the only test that doesn't need Docker, which
@@ -141,7 +140,7 @@ A summary table prints at the end of the session.
 
 - **No xdist.** Parallel runs make timings noisy; benchmarks run sequentially.
 - **Redis vs Valkey.** Each adapter is paired with its natural server
-  (redis-py → redis, valkey-py / redis-rs / valkey-glide → valkey,
+  (redis-py → redis, valkey-py / valkey-glide → valkey,
   django (builtin) → redis). Cross-pairings are intentionally not in the
   matrix: both servers speak the same protocol, so the comparison is
   mostly a wash.
@@ -164,7 +163,6 @@ run; ordering is what matters.
 | redis-py+hiredis     |  2,332 |    2,480 |  2,281 | 1,515 | 1,345 |  2,506 |  1,209 |         51 |
 | valkey-py            |  2,783 |    2,956 |  2,695 | 1,595 | 1,418 |  2,978 |  1,437 |        109 |
 | valkey-py+libvalkey  |  2,821 |    2,973 |  2,741 | 1,695 | 1,508 |  3,040 |  1,465 |         48 |
-| **redis-rs**         |  9,651 |   13,396 | 11,151 | 2,967 | 4,520 | 13,226 |  5,894 |         29 |
 | **valkey-glide**     |  6,982 |    8,783 |  6,982 | 2,030 | 1,916 |  8,901 |  3,994 |         29 |
 | django (builtin)     |  2,307 |    2,459 |  2,269 | 1,501 | 1,347 |  1,947 |  1,199 |         51 |
 
@@ -178,7 +176,6 @@ One cache op per request through the full middleware/URL/view path.
 | redis-py+hiredis     | 1,065 |    1,181 | 1,131 |   866 |   807 | 1,168 |  1,173 |
 | valkey-py            | 1,089 |    1,299 | 1,241 |   891 |   836 | 1,276 |  1,282 |
 | valkey-py+libvalkey  | 1,053 |    1,306 | 1,248 |   924 |   861 | 1,290 |  1,300 |
-| **redis-rs**         | 1,382 |    2,044 | 2,001 | 1,265 | 1,490 | 1,995 |  2,005 |
 | **valkey-glide**     | 1,237 |    1,863 | 1,753 | 1,023 |   994 | 1,816 |  1,838 |
 | django (builtin)     |   861 |    1,177 | 1,133 |   859 |   806 | 1,016 |  1,169 |
 
@@ -192,7 +189,6 @@ One `await` at a time.
 | redis-py+hiredis     | 1,815 |    1,913 | 1,729 | 1,199 |   849 | 1,911 |    915 |
 | valkey-py            | 2,080 |    2,184 | 2,039 | 1,331 |   854 | 2,190 |  1,055 |
 | valkey-py+libvalkey  | 2,075 |    2,187 | 2,029 | 1,329 |   852 | 2,176 |  1,049 |
-| **redis-rs**         | 6,862 |    8,238 | 7,517 | 2,474 | 3,560 | 8,265 |  3,952 |
 | **valkey-glide**     | 3,300 |    3,738 | 3,297 | 1,725 | 1,678 | 3,693 |  1,735 |
 | django (builtin)     | 1,948 |    1,995 | 1,929 |   199 |   197 |   989 |    992 |
 
@@ -207,7 +203,6 @@ actually generate.
 | redis-py+hiredis     |  2,121 |    2,254 |  2,047 | 1,347 |   931 |  2,149 |    979 |        106 |
 | valkey-py            |  2,465 |    2,591 |  2,327 | 1,229 |   920 |  2,569 |  1,130 |         58 |
 | valkey-py+libvalkey  |  2,467 |    2,588 |  2,329 | 1,223 |   917 |  2,564 |  1,129 |        108 |
-| **redis-rs**         | 22,335 |   35,848 | 28,528 | 2,508 | 6,533 | 39,406 |  5,543 |        108 |
 | **valkey-glide**     | 10,149 |   12,575 | 10,045 | 2,074 | 2,607 | 12,232 |  2,627 |        109 |
 | django (builtin)     |  2,078 |    2,177 |  2,076 |   212 |   210 |  1,051 |  1,018 |        107 |
 
@@ -222,36 +217,28 @@ six async cache ops, the shape closest to real production load.
 | redis-py+hiredis     |   467 |    213 |  1,509 |            414 |        209 |           209 |
 | valkey-py            |   519 |    192 |  1,375 |            420 |        211 |           211 |
 | valkey-py+libvalkey  |   498 |    200 |  1,599 |            432 |        211 |           211 |
-| **redis-rs**         |   607 |    164 |  1,152 |            430 |        115 |           115 |
 | **valkey-glide**     |   553 |    180 |  1,395 |            446 |        172 |           172 |
 | django (builtin)     |   156 |    634 |  3,117 |            466 |        337 |           337 |
 
 ### Takeaways
 
-- **Sync direct.** `redis-rs` leads on every phase at **~10k get / 11k set
-  / 13k incr / 6k delete** ops/sec, ~4× the fastest pure-Python adapter.
-  `valkey-glide` is second on single-key ops (`get`/`set`/`incr` ~7–9k)
-  but trails `redis-rs` on multi-key and `delete`. Both Rust adapters
-  use ~4× less Python memory than the pure-Python adapters.
-- **Django request cycle.** Both Rust adapters lead the table:
-  `redis-rs` ~1.4–2.1k ops/sec, `valkey-glide` ~1.2–1.9k. Earlier
-  versions of these adapters failed this benchmark entirely because
-  ``close()`` was tearing down the connection on every
-  ``request_finished`` signal; now they outperform the Python adapters.
-- **Async serial.** `redis-rs` runs **~3–4× faster** than the C-parser
-  Python adapters on every phase (6.9k get, 8.3k incr). `valkey-glide`
-  is also faster than Python (~1.5–1.8×) but trails `redis-rs`.
-- **Async concurrent (50 in flight).** `redis-rs` peaks at **22k get /
-  36k get-miss / 39k incr** ops/sec, which is **9–18×** the fastest Python
-  adapter. `valkey-glide` is half that rate but still **~4×** ahead of
-  the Python adapters.
+- **Sync direct.** `valkey-glide` leads every phase at **~7k get / 7k set
+  / 8.9k incr / 4k delete** ops/sec, ~2.5× the fastest pure-Python adapter,
+  and uses ~4× less Python memory.
+- **Django request cycle.** `valkey-glide` leads at ~1.2–1.9k ops/sec.
+  An earlier version failed this benchmark entirely because ``close()``
+  was tearing down the connection on every ``request_finished`` signal;
+  now it outperforms the Python adapters.
+- **Async serial.** `valkey-glide` runs ~1.5–1.8× faster than the C-parser
+  Python adapters on every phase (3.3k get, 3.7k incr).
+- **Async concurrent (50 in flight).** `valkey-glide` peaks at **10k get /
+  12.5k get-miss / 12.2k incr** ops/sec, roughly **4–5×** the fastest
+  Python adapter.
 - **ASGI full-stack** (granian × 4 workers, httpx × 100 concurrent).
-  Both Rust adapters lead on req/s: `redis-rs` 607 (164 ms avg, 1.15 s
-  p99) and `valkey-glide` 553. They also use **fewer connections** than
-  every Python adapter (`redis-rs` 115, `valkey-glide` 172, vs Python ~210).
-  Process-wide client sharing (added after this benchmark first
-  surfaced 1,111 / 4,577 conn counts) brought the Rust adapters in
-  line with the multiplexed-transport claim.
+  `valkey-glide` leads on req/s at 553 (180 ms avg, 1.4 s p99) and uses
+  fewer connections than every Python adapter (172 vs ~210). Process-wide
+  client sharing, added after this benchmark first surfaced 4,577 conn
+  counts, brought it in line with its transport's claim.
 - **Connection stability.** Across every shape the cachex path keeps
   `Δ` at 0 between phases, so there are no per-phase connection leaks on
   any adapter.

{django_cachex-0.4.2 → django_cachex-0.5.0}/django_cachex/__init__.py

@@ -1,10 +1,4 @@
 from importlib.metadata import PackageNotFoundError, version
-from pkgutil import extend_path
-
-# Extend the package path so the optional django-cachex-redis-rs binary package
-# (which ships ``adapters/_redis_rs*`` files into this namespace) is
-# discovered when both packages are installed side by side.
-__path__ = extend_path(__path__, __name__)
 
 try:
     __version__ = version("django-cachex")
@@ -19,7 +13,7 @@ from django_cachex.exceptions import (
     SerializerError,
     WrongTypeError,
 )
-from django_cachex.lock import AsyncLock, Lock, LockError, LockNotOwnedError
+from django_cachex.lock import LockError, LockNotOwnedError
 from django_cachex.script import (
     ScriptHelpers,
     decode_list_post,
@@ -35,11 +29,9 @@ from django_cachex.semaphore import (
 from django_cachex.stampede import StampedeConfig
 
 __all__ = [
-    "AsyncLock",
     "AsyncPipeline",
     "CachexError",
     "CompressorError",
-    "Lock",
     "LockError",
     "LockNotOwnedError",
     "NotSupportedError",

{django_cachex-0.4.2 → django_cachex-0.5.0}/django_cachex/adapters/__init__.py

@@ -1,18 +1,10 @@
 """Adapter layer: low-level Redis/Valkey ops per driver.
 
 Each adapter wraps a specific underlying client library (redis-py,
-valkey-py, our Rust ``redis-rs`` driver, valkey-glide) and exposes the
-operation surface that ``RespCache`` delegates to.
+valkey-py, valkey-glide) and exposes the operation surface that
+``RespCache`` delegates to.
 """
 
-from pkgutil import extend_path
-
-# Extend the sub-package path so the optional ``django-cachex-redis-rs``
-# binary package (which ships ``_redis_rs*`` files into this namespace)
-# is discovered when the two packages are installed under different
-# prefixes.
-__path__ = extend_path(__path__, __name__)
-
 from django_cachex.adapters.pipeline import AsyncPipeline, Pipeline
 from django_cachex.adapters.protocols import (
     RespAdapterProtocol,
@@ -26,13 +18,6 @@ from django_cachex.adapters.redis_py import (
     RedisPyPipelineAdapter,
     RedisPySentinelAdapter,
 )
-from django_cachex.adapters.redis_rs import (
-    RedisRsAdapter,
-    RedisRsAsyncPipelineAdapter,
-    RedisRsClusterAdapter,
-    RedisRsPipelineAdapter,
-    RedisRsSentinelAdapter,
-)
 from django_cachex.adapters.valkey_glide import (
     ValkeyGlideAdapter,
     ValkeyGlideAsyncPipelineAdapter,
@@ -55,11 +40,6 @@ __all__ = [
     "RedisPyClusterAdapter",
     "RedisPyPipelineAdapter",
     "RedisPySentinelAdapter",
-    "RedisRsAdapter",
-    "RedisRsAsyncPipelineAdapter",
-    "RedisRsClusterAdapter",
-    "RedisRsPipelineAdapter",
-    "RedisRsSentinelAdapter",
     "RespAdapterProtocol",
     "RespAsyncPipelineProtocol",
     "RespPipelineProtocol",

{django_cachex-0.4.2 → django_cachex-0.5.0}/django_cachex/adapters/pipeline.py

@@ -8,8 +8,6 @@ implementation, one per driver:
 - :class:`~django_cachex.adapters.valkey_py.ValkeyPyPipelineAdapter` /
   :class:`~django_cachex.adapters.redis_py.RedisPyPipelineAdapter`: wrap a
   redis-py / valkey-py / cluster ``Pipeline`` object.
-- :class:`~django_cachex.adapters.redis_rs.RedisRsPipelineAdapter`:
-  buffers RESP wire commands for the Rust driver's ``pipeline_exec``.
 - :class:`~django_cachex.adapters.valkey_glide.ValkeyGlidePipelineAdapter`:
   drives ``valkey-glide``'s ``Batch``.
 
@@ -1606,8 +1604,8 @@ class Pipeline:
 class AsyncPipeline(Pipeline):
     """Async sibling of :class:`Pipeline`: same chainable API, awaitable ``execute()``.
 
-    Driver async pipelines (``redis.asyncio`` ``Pipeline``, glide async ``Batch``,
-    redis-rs ``apipeline_exec``) all expose the same chainable command surface
+    Driver async pipelines (``redis.asyncio`` ``Pipeline``, glide async ``Batch``)
+    all expose the same chainable command surface
     as their sync counterparts; only execution does I/O. So this subclass
     inherits every queueing method from :class:`Pipeline` and only overrides
     the lifecycle (``__aenter__/__aexit__``) and ``execute()`` to be async.

{django_cachex-0.4.2 → django_cachex-0.5.0}/django_cachex/adapters/protocols.py

@@ -11,7 +11,6 @@ pipeline layers rely on.
   :class:`~django_cachex.cache.resp.RespCache` calls on its
   underlying adapter. Concrete adapters
   (:class:`~django_cachex.adapters.valkey_py.ValkeyPyAdapter`,
-  :class:`~django_cachex.adapters.redis_rs.RedisRsAdapter`,
   :class:`~django_cachex.adapters.valkey_glide.ValkeyGlideAdapter`)
   inherit from this Protocol so the contract is explicit at the class
   declaration; the inherited method bodies (``...``) are shadowed by each

{django_cachex-0.4.2 → django_cachex-0.5.0}/django_cachex/adapters/valkey_py.py

@@ -67,7 +67,7 @@ _set = set
 # process-wide registry every async cache call would open a brand-new
 # TCP connection, which is slow on the hot path and noisy on the server. Sharing
 # pools at the module level by event loop + config keeps connections
-# reused across tasks, in line with the multiplexed redis-rs adapter.
+# reused across tasks.
 #
 # The registry itself lives on each driver-specific adapter class as the
 # ``_async_pools`` class attribute (see :mod:`~django_cachex.adapters.redis_py`
@@ -375,7 +375,7 @@ class ValkeyPyAdapter(RespAdapterProtocol):
         """Get an async client connection.
 
         ``async def`` for Protocol uniformity: adapters whose async-client
-        construction is genuinely async (glide, redis-rs) ``await`` here;
+        construction is genuinely async (glide) ``await`` here;
         for redis-py / valkey-py the body is sync (pool lookup +
         ``Redis(connection_pool=...)``) since the connection opens
         lazily on the first awaited command.

{django_cachex-0.4.2 → django_cachex-0.5.0}/django_cachex/cache/__init__.py

@@ -10,11 +10,6 @@ from django_cachex.cache.redis_py import (
     RedisClusterCache,
     RedisSentinelCache,
 )
-from django_cachex.cache.redis_rs import (
-    RedisRsCache,
-    RedisRsClusterCache,
-    RedisRsSentinelCache,
-)
 from django_cachex.cache.resp import RespCache, RespClusterCache, RespSentinelCache
 from django_cachex.cache.stream import StreamCache
 from django_cachex.cache.tiered import TieredCache
@@ -30,9 +25,6 @@ __all__ = [
     "LocMemCache",
     "RedisCache",
     "RedisClusterCache",
-    "RedisRsCache",
-    "RedisRsClusterCache",
-    "RedisRsSentinelCache",
     "RedisSentinelCache",
     "RespCache",
     "RespClusterCache",

{django_cachex-0.4.2 → django_cachex-0.5.0}/django_cachex/cache/resp.py

@@ -7,7 +7,6 @@ concrete subclasses live in:
 
 - :mod:`django_cachex.cache.valkey_py`: ``valkey-py``
 - :mod:`django_cachex.cache.redis_py`: ``redis-py``
-- :mod:`django_cachex.cache.redis_rs`: Rust ``redis-rs`` driver
 - :mod:`django_cachex.cache.valkey_glide`: ``valkey-glide``
 """
 

{django_cachex-0.4.2 → django_cachex-0.5.0}/django_cachex/cache/stream.py

@@ -12,7 +12,7 @@ Configuration::
 
     CACHES = {
         "redis": {
-            "BACKEND": "django_cachex.cache.RedisCache",  # or RedisRsCache, etc.
+            "BACKEND": "django_cachex.cache.RedisCache",  # or ValkeyCache, etc.
             "LOCATION": "redis://127.0.0.1:6379/0",
         },
         "default": {

{django_cachex-0.4.2 → django_cachex-0.5.0}/django_cachex/exceptions.py

@@ -72,7 +72,7 @@ class WrongTypeError(CachexError, TypeError):
     of value``. Subclasses both :class:`CachexError` and :class:`TypeError`,
     so ``except CachexError`` and existing ``except TypeError`` callers both
     keep working while new code can catch this specifically across backends
-    (LocMem, redis-py, valkey-py, valkey-glide, redis-rs).
+    (LocMem, redis-py, valkey-py, valkey-glide).
     """
 
 

django_cachex-0.5.0/django_cachex/lock.py

@@ -0,0 +1,11 @@
+"""Exceptions every adapter's ``cache.lock()`` object raises, whichever it is."""
+
+from django_cachex.exceptions import CachexError
+
+
+class LockError(CachexError):
+    """Raised when a lock operation fails."""
+
+
+class LockNotOwnedError(LockError):
+    """Raised when releasing or extending a lock the caller no longer owns."""

{django_cachex-0.4.2 → django_cachex-0.5.0}/django_cachex/semaphore.py

@@ -7,7 +7,7 @@ rest of the project's convention (``foo``/``afoo``):
   ``_SemaphoreRegistry`` shared by every cache with the same LOCATION;
   standalone instances share a process-wide registry.
 - :class:`RespSemaphore`: backed by Lua scripts dispatched through any
-  ``RespAdapterProtocol`` (redis-py, redis-rs, valkey-py, valkey-glide).
+  ``RespAdapterProtocol`` (redis-py, valkey-py, valkey-glide).
   Constructed by ``cache.semaphore(...)`` / ``cache.asemaphore(...)`` and not
   exposed at the package root.
 

{django_cachex-0.4.2 → django_cachex-0.5.0}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "django-cachex"
-version = "0.4.2"
+version = "0.5.0"
 description = "Full featured Valkey and Redis cache backend for Django"
 readme = "README.md"
 license = "MIT"
@@ -32,9 +32,6 @@ valkey-py = ["valkey>=6.1.0,<7"]
 libvalkey = ["valkey[libvalkey]>=6.1.0,<7"]
 redis-py = ["redis>=6,<9"]
 hiredis = ["redis[hiredis]<9,>=6"]
-# Rust I/O driver: separate binary package, prebuilt wheels for Linux x86_64/aarch64,
-# macOS arm64, and Windows amd64 (cp314 and cp314t).
-redis-rs = ["django-cachex-redis-rs==0.4.2"]
 # valkey-glide: Rust-cored Valkey client. Sync and async are separate distributions.
 valkey-glide = ["valkey-glide-sync>=2.3,<3", "valkey-glide>=2.3,<3"]
 # Compressors
@@ -58,7 +55,6 @@ dev = [
   "django-stubs==6.1.0",
   "djlint==1.44.2",
   "lz4==4.4.5",
-  "maturin==1.14.1",
   "msgpack==1.2.1",
   "ormsgpack==1.12.2",
   "mypy==2.3.0",
@@ -77,8 +73,6 @@ dev = [
   # ASGI benchmark only: granian (real ASGI server) plus httpx (load gen).
   "granian>=2.6,<3",
   "httpx>=0.28,<0.29",
-  # Rust I/O driver: workspace member so `uv sync` builds it for tests/benchmarks
-  "django-cachex-redis-rs",
   # Full example: workspace member so its deps (notably celery) survive
   # ``uv sync``, which the pre-commit hook runs on every commit.
   "django-cachex-full-example",
@@ -96,20 +90,14 @@ build-backend = "hatchling.build"
 
 [tool.hatch.build.targets.wheel]
 packages = ["django_cachex"]
-# _redis_rs.pyi is the type stub for the optional Rust extension. It lives
-# alongside django_cachex source so type checkers find it during dev, but
-# it ships with the django-cachex-redis-rs binary package, not this one.
-exclude = ["**/_redis_rs.pyi"]
 
 [tool.hatch.build.targets.sdist]
 include = ["django_cachex/**", "README.md", "LICENSE", "pyproject.toml"]
-exclude = ["**/_redis_rs.pyi"]
 
 [tool.uv.workspace]
-members = ["crates/*", "examples/full"]
+members = ["examples/full"]
 
 [tool.uv.sources]
-django-cachex-redis-rs = { workspace = true }
 django-cachex-full-example = { workspace = true }
 
 [tool.ruff]

django_cachex-0.4.2/crates/django-cachex-redis-rs/LICENSE

@@ -1,21 +0,0 @@
-MIT License
-
-Copyright (c) 2026 Oliver Haas <ohaas@e1plus.de>
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.

django_cachex-0.4.2/crates/django-cachex-redis-rs/README.md

@@ -1,23 +0,0 @@
-# django-cachex-redis-rs
-
-Rust adapter for [django-cachex], built on PyO3 + tokio + [redis-rs].
-
-This is a binary-only companion package that ships the compiled
-`_redis_rs` extension module into the `django_cachex.adapters`
-namespace. Install via the `redis-rs` extra on the main package:
-
-```console
-pip install django-cachex[redis-rs]
-```
-
-Prebuilt wheels are published for Linux x86_64, Linux aarch64, macOS
-arm64, and Windows amd64, on both cp314 and cp314t (free-threaded). On
-other platforms there's no wheel, so pip will try to build from source
-(requires the Rust toolchain) or fail clearly.
-
-The pure-Python `django-cachex` package is fully usable on its own; this
-binary just unlocks the `RedisRsCache` family of
-backends.
-
-[django-cachex]: https://github.com/oliverhaas/django-cachex
-[redis-rs]: https://github.com/redis-rs/redis-rs

django_cachex-0.4.2/crates/django-cachex-redis-rs/pyproject.toml

@@ -1,45 +0,0 @@
-[project]
-name = "django-cachex-redis-rs"
-version = "0.4.2"
-description = "Rust adapter (PyO3 + tokio + redis-rs) for django-cachex"
-readme = "README.md"
-license = { text = "MIT" }
-requires-python = ">=3.14"
-authors = [{ name = "Oliver Haas", email = "ohaas@e1plus.de" }]
-keywords = ["django", "valkey", "redis", "cache", "rust"]
-classifiers = [
-  "Development Status :: 4 - Beta",
-  "Environment :: Web Environment",
-  "Framework :: Django",
-  "Framework :: Django :: 6.0",
-  "Intended Audience :: Developers",
-  "License :: OSI Approved :: MIT License",
-  "Operating System :: MacOS",
-  "Operating System :: Microsoft :: Windows",
-  "Operating System :: POSIX :: Linux",
-  "Programming Language :: Python",
-  "Programming Language :: Python :: 3",
-  "Programming Language :: Python :: 3 :: Only",
-  "Programming Language :: Python :: 3.14",
-  "Programming Language :: Python :: Free Threading :: 1 - Unstable",
-  "Programming Language :: Rust",
-  "Topic :: Internet :: WWW/HTTP",
-  "Topic :: Software Development :: Libraries",
-  "Topic :: Utilities",
-  "Typing :: Typed",
-]
-
-[project.urls]
-Homepage = "https://github.com/oliverhaas/django-cachex"
-Repository = "https://github.com/oliverhaas/django-cachex.git"
-
-[build-system]
-requires = ["maturin>=1.13,<2.0"]
-build-backend = "maturin"
-
-[tool.maturin]
-module-name = "django_cachex.adapters._redis_rs"
-features = ["pyo3/extension-module"]
-python-source = "python"
-manifest-path = "Cargo.toml"
-include = ["LICENSE"]