Should we stop recommending pylibmc?

The caching docs recommend using pylibmc or pymemcache for caching using memcached.

However, there’s an exception swallowed on startup under Python 3.13 that has been fixed since July 2024, but there hasn’t been a pylibmc release since 2022.

Granted, the situtation with pymemcache isn’t significantly better (no releases in 3 years either, but at least their CI does target py313, albeit with a version of gevent that is too old to compile in the test requirements).

So I have to wonder out loud: should we stop recommending pylibmc without better maintenance?

3 Likes

+1 for me, definitely not recommending anything that is not touched for a few years.

I’ve never used memcached though. I’m wondering if there are any other alternatives for python clients?

1 Like

python-memcached has a release supporting 3.12 from Jan 2024, and their CI also tests against 3.13.

1 Like

Reading up on the history, the Django backend for python-memcached was deprecated in Django 3.2 and removed in 4.1. It’s unfortunate that now it might be in one of the better maintenance postures. Maybe that counsels against deprecating anything else.

We should do something about referencing that library in our docs. An alternative is to reference pylibmc2 which is a new fork. The person who created it is the one who is offering to help maintain pylibmc. They just haven’t heard back/gotten access.

2 Likes

Another alternative would be to “deprioritize” or “de-emphasize” the use of memcached as the cacheing engine, preferring instead to recommend one of the other options.

2 Likes

That fork is only five commits ahead of the upstream fork, with a bunch of release tooling updates. At a glance, it doesn’t look like there’s anything shady there, but it would be nice to know of folks using it in production and verifying that’s it’s not malware before we recommend it.

We should do something before the Django 7.0 branch is cut in January. If no one can vouch for pylibmc2, I think we need to deprecate all of the memcached clients, and we should do that in Django 6.2.

mxamin, the maintainer of pylibmc2, has been working on another open source package for a while. I think it’s probably fine to maintain. Another option is to fork it into Django’s org or Django Commons.

I think we just need the lights to be kept on for this package. There is some clean up that can be done (remove py2.7, swap out nose, etc), but it seems largely fine as is.

cc-ing @steering_council for others to chime in with thoughts. This is becoming a priority for us quickly.

Yep, I think we should at least deemphasise. (Possibly even warn against.)

IIRC from recent surveys most folks are using either DB or Redis (or compatible) backends. We should point there, in the main.

I’m not aware that there are folks who have capacity to pick up maintenance here—keeping the lights on is more than it sounds if we’re about more than just one time updates—so I’d be sceptical about making a move that falsely signals otherwise. (But maybe there are folks…?)