While reading the release notes for a recent update of python-social-auth I was thinking about how I handle User-Agent headers in django apps.

Usually you can run an application without knowing what language it is written in. Sometimes when debugging unexpected behavior, that becomes very important. While debuging some headers changing, knowing that Caddy was written in [golang] explained the bug.

Python uses a list of “Trove classifiers ” to add some structured meta data to projects. It can be a bit tedius to add these manually. Combining the ease of uvx with a Python package, we can simplify this.

My previous post about packaging was several years ago. With the raising popularity of uv and just, I have updated my basic packaging steps.

Inspired by @adamghill ’s recent dj-toml-settings and webology ’s previous post on renaming django-admin I did a quick brainstorm of a django-uv command.

Now that just made it into debian trixie , it has become easier to install it everywhere. I have recently been updating some of my dev environment, and have started using it with my existing salt configuration to make it easier while testing.

On my phone and tablet, I typically use safari as a default, always in private mode, and I use Vivaldi for a few sites I want to keep a persistent session. I will periodically do a “Close all Tabs” for my browser and save links to something like Raindrop. On my desktop I currently use Vivaldi mostly like normal, though I do miss Firefox Multi-Account Containers for separating things. Somewhat inspired by Firefox Multi-Account Containers , I have long brainstormed about some browser ideas, even if they’re not super original.

If we understand what files git rebase creates, then we can manually create our own rebase plan.

# Lets check out a branch to work with
git checkout origin/main demo-branch
# and kick off a rebase against root
git rebase -i --root

I have never had a beer. I have never had a glass of wine. I will often joke that as an computer science major, I was busy studying and never attended parties so I just never started. At first, it was not not any kind of specific decision and I have no religious reason for abstaining, I just never started. Over time I made a more conscious decision that I did not have a compelling reason to start and just never did.

I have been using salt for quite a while (oldest commit in my personal salt states repo is 2010), but have usually taken the old approach to distributing modules. By setting the file_roots you can automatically sync all your modules with the saltutil.sync_all command.

file_roots:
  base:
    - /srv/salt
    - /srv/salt-kafka
    - /srv/salt-forgejo

With our file_roots defined, our plugin repo looks like this

tree /srv/salt-kafka
├── LICENSE
├── README.md
└── _engines
    └── kafka_consumer.py

This is useful, but for maintainability, I finally sat down to look at how to package things up more properly.