My first open source contributions are old enough to have a beer in the US by now, as is my first python code. But I’ve always found it awkward and disruptive to patch, and contribute a patch back to a library that I’m using in a python project, especially when I’m working with virtualenv or similar setups. With poetry and git, I’ve finally settled on one I like, and I’m capturing it here for easy reference next time.

Poetry is, by quite some distance, my favorite way to manage python dependencies these days. But for modifying open source dependencies and contributing changes back, my workflow has always been awkward. I’ve often resorted to temporarily “vendoring” a project, or to awkward virtual environment manipulations. Here’s an easier way.

As I’ve mentioned a few times, HTMX is really growing on me for building web things lately. When stacked on top of Django, it lets me mostly write server side code, which is my comfort zone, but get pages that load and behave the way people expect them to in 2022. It doesn’t free me from all need to write stuff that runs in the browser, though. Here’s what I’ve found useful lately.

In part 4 of this series, we got forms in place to add and edit books in the library, then made them look better using django-crispy-forms. The many-to-many relationship between books and authors brought some weaknesses of the Crispy Tailwind theme to light, and it took a bit of effort to address that. Now it’s time to get deletion working before we make everything work a little better using HTMX.

In part 1 and part 2, we got the basic project workflow set up. Part 3 saw some initial models and views that were tested using the Django admin UI. Now it’s time to add library CRUD to the reading_log application itself.

I’m blogging this because I find myself looking it up repeatedly. Every time I start a project, I eventually hit a point where I use the REPL quite a bit. Usually I want to use it from PyCharm’s python console. And I usually find myself manually typing 5 or 6 commands at the start of each session that shell_plus from django-extensions would give me for free.

In part 1 and part 2, we got the basic project workflow set up. Now it’s time to add some basic models and views.

In part 1, I set up the project, a sensible .gitignore, tailwind, and live reloading along with some run targets for PyCharm. Now it’s time to finish up the housekeeping.

I wanted to try out some “modern” front-end development for a while, and I did. FastAPI is great. So is Svelte. But even though I found creating APIs that way to be a breeze, building a whole site that way felt much slower and heavier than using traditional server rendering. So I decided to give django a fair shake for a while, and I’m glad I did. Here’s how I currently like to get a site started with django, using Tailwind CSS for responsive layouts and styling, and mixing in alpine.js and HTMX to make the site feel reactive. I’m glad I gave the backend/frontend split an honest try, but this fits the way I think about sites better.

I feel like restarting the blog. Let’s see how long it sticks this time. My goal is at least 100 posts in the next 12 months.

As good as existing editing tooling for LÖVE2D, sometimes source debugging is hard to beat.