Publ’s insurmountable technical debt

Comments

Back when Publ was brand-new I was using a fairly common ORM for managing my database. It was okay but I had some issues with how the project was being run, particularly in how the core maintainer treated bug reporters who were reporting things that he didn’t personally agree with.

So I switched to Pony ORM, which has a much nicer, more-Pythonic API, and whose maintainers are friendly and helpful. It’s missing a few important functions such as migrations but for Publ it doesn’t matter so much and they were always claiming that migrations were coming “real soon now” for a while.

Unfortunately, some changes in Python 3.11 broke Pony completely, and progress on getting it working again has been, well, slow.

Back when I switched to Pony I mused about just dropping SQL entirely and moving to a more primitive indexed data store, such as lmdb. But I really do not have it in me to completely redo all that stuff in Publ again, especially with all of the weird regressions that always occur due to subtle differences in locking behavior and so on.

Sometimes I think how now that I actually know how Publ should work I should rewrite it with better testability and a more actively-developed Markdown processor (because misaka has also been abandoned and is in permafreeze status), and if I’m going to do that, maybe I should use it as an excuse to finally learn Rust because honestly the Python ecosystem is kind of a mess right now.

I’ve put so much work into Publ but keeping the project going just feels so… difficult.

Or I mean I could switch to any number of existing site generators out there but then I’d be giving up all of the things that makes Publ unique (friends-only/access-controlled entries, variadic templates, top-notch template-driven image renditions, etc.).

This is one of those things where the decision would be a lot easier to make if people were actually helping to fund Publ development or if it had any actual, y'know, users.

Read more…