We’re solidly mid-cycle on Django now. That means looking towards Django 4.0. The feature freeze isn’t until September. Lots of time, in theory; the reality is not.
Every week there’s a (remarkable, really) barrage of new issues come in and tasks to deal with. That’s fine. That’s why the Fellowship Program exists. But it doesn’t leave much time for taking on the wish list. A little focus-cum-hustle goes a long way.
There’s a PR to switch Form rendering to the template engine that I managed to get back to this week. I want to get this knocked off in the next couple of weeks.
After that, I want to swing back to finishing off the proposal for SECRET_KEY rotation begun by Andreas Pelme. Which should leave more than enough time to bring-in the zoneinfo backed timezone implementation that we’ve talked about before.
That’s already plenty. 😳
Google Summer of Code (GSoC) projects were announced this week. We were awarded four slots: two on Django itself, and two for Wagtail, who came in under the Django umbrella this year.
Wagtail, I think, would have taken more projects, so (assuming a good experience this year) it would be great for them to apply independently next year being able to say, look, we had this super experience last year. (Or that would be the idea at least.)
For Django we have Manav, working on the migrations internals, and Daniyal, working on adding a Redis cache backend. (Please welcome Manav and Daniyal if you see them on the forum/mailing list/IRC.)
There’s long been discussion of whether to add a Redis cache backend in core. The survey last year revealed ≈ twice as many users using Redis for caching than memcached. That was kind-of compelling.
The built-in backend won’t offer some of the more advanced features — choice of serialiser for instance — since these don’t apply across the existing backends (yet). What it will mean, though, is that you won’t have to stop and do the due-diligence on how do I use Redis for caching? 🤔 just to get started. You can likely go a long way before you need to look into more advanced.
Personally, the migrations project is a nice chance for me to up my chops there. It’s still one of those areas that I wince a bit to look at.
The Wagtail projects are quite exciting too. They have one to provide a cross-db search backend, and one in the real-time realm to push updates out in a live-blog type idea.
The search project is interesting, and I hope something that maybe leads to things being pushed back upstream to Django.
For a long-time the underlying position was (I take it) that, whilst the ORM in-theory allowed database portability, you weren’t ever really going to change database, so it was somewhat moot. Unless you had reasons otherwise, the default choice was PostgreSQL, and that’s what you were going to go with.
Well, since the GSoC project adding the cross-db JSONField a couple of summers ago, that’s not so clear anymore. For many (most?) cases I can get by quite happily with SQLite. And that means my project can run on the smallest of instances for less that a movie ticket all year, and I can deal with scaling it up, or adding an RDS later, if and when it needs it.
Except for search, where if I want to use the ORM’s full-text search features I’m still stuck with Postgres. There’s nothing wrong with that, Postgres rocks. There’s a reason it’s the default choice. But SQLite is perfectly capable here. (There’s a few options, Simon Willison, as ever, has a good discussion, with code.) If we could do cross-db FTS within the remit of the ORM, I wonder if Postgres is the default (together with You won’t really change DB) would continue to be so (shall we say?) obvious. Anyhow… 🧐
I’m also interested to see how the Wagtail Live project turns out. With HTMX making such a splash in the community, and I continue to be enamoured the more I use it, the impetus to push forward with the real-time stuff within the bounds of a small team is renewed.
It becomes easy to start: I can poll — it’s automatic. Then it’s not far from there to a Channels consumer sending SSEs. And websockets don’t then seem such a jump. What’s nice is you can build up to it.
On the Channels front we’ve got a PR to add a Redis PubSub based channel layer. It looks great. I’m quite excited about it because it should (in theory) perform a lot better than the existing layer, where we do the broadcast ourselves. This, and the next round of Channels updates are on my list for the period after DjangoCon EU.