For the first time in quite a while, I caught the urge to publish a package to pypi today. The happy path for publishing a pure python package felt less obvious than I think it should’ve. Here’s what I did.

After a few years' layoff, I’m playing fantasy baseball again in 2024. Not only is this league quite a bit different from the one I used to play, the online resources for player research have changed over the past few years. This post collects some things that seem useful to me.

I’m blogging today’s yak shaving exercise because I found web searches challenging for some of this. And hopefully writing them down here will both help improve those searches and help me remember. Also, I am determined to blog more in 2024.

Over the past week or so, I’ve been trying out using Docker to deploy a Django site on a VPS. My preferred setup for that is to have Caddy running on the host, not in any container, as a reverse proxy. (It’s a single, static binary; I don’t see any joy in wrapping that in a container.) In the past when I’ve hosted similar things, I just ran gunicorn in a python virtualenv on the host as well, and bound it to the loopback. The current thing I’m building is a little bit more painful to run that way on my VPS, so I thought I’d finally cave and give Docker a try in “production.” While there was quite a bit to like about it, there was also an unpleasant surprise.

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.