Recently like a lot of my Python follows, I have been using uv to manage a lot of my python projects.

Given a project, uv tree will show you a nice tree view of your requirements.

wheat v0.1.0
├── click v8.1.8
├── inquirer v3.4.0
│   ├── blessed v1.20.0
│   │   ├── six v1.17.0
│   │   └── wcwidth v0.2.13
│   ├── editor v1.6.6
│   │   ├── runs v1.2.2
│   │   │   └── xmod v1.8.1
│   │   └── xmod v1.8.1
│   └── readchar v4.2.1
└── tomlkit v0.13.2

You can also do something like uv pip list to show it in list form. Both support a --outdated flag to show you packages needing updates.

Mostly for scripting reasons and alerting reasons, there are multiple times when I have wanted a simple status of a repository. When working from the console, there is git-status which shows things in a human parsable format, but for scripts we need something more robust.

We can ue git-status with the –porcelain=2 flag to provide a lot more information, in a more easily machine parsable format. Seeing how starship parsed git-status helped me on this path.

Using this information, I wrote my own git-pending command to parse this data, into a form I could script against more easily.

I tend to use my calendar and reminders to track a lot of what I want to do, but sometimes I want to manage the data externally and sync. For certain kinds of repeating tasks, I wanted to edit a list of tasks in a group, and it seemed like csv might work. While csv does not have a strong specification, many programming tools make it easy to work with. The initial format I thought about was something simple.

One advantage of having my own personal api is that I can put various useful scripts under a single repo and have them run. I have been using raindrop for several years, to collect bookmarks to read later. Often, while researching things, it would be useful to automatically group things into collections, so I wrote some celery tasks to help with this.

I have long been inspired by Aaron Pareki and his pk3 tool for his website. With some searching, one can find other kinds of personal management systems on GitHub or other developers writing about their own personal api with links to other examples. As a developer myself, I have my own personal API that I am able to add to as wanted.

In the interest of choosing boring technology my personal api is powered primarily by django and celery .

Django comes with support for MIDDLEWARE and provides several useful ones by default. I usually try to make my projects as useable as possible, and some debug middleware is only useful when development.

Example Middleware

Since the order and layering often matter, I’ll usually configure all my optional middleware in the correct spot like bellow, with a short comment.

MIDDLEWARE = [
    "debug_toolbar.middleware.DebugToolbarMiddleware",  # Only enabled for debug
    "django.middleware.security.SecurityMiddleware",
    "whitenoise.middleware.WhiteNoiseMiddleware",  # Used primarily for docker
    "django.middleware.locale.LocaleMiddleware",
    "django.contrib.sessions.middleware.SessionMiddleware",
    "django.middleware.common.CommonMiddleware",
    "django.middleware.csrf.CsrfViewMiddleware",
    "django.contrib.auth.middleware.AuthenticationMiddleware",
    "django.contrib.messages.middleware.MessageMiddleware",
    "django.middleware.clickjacking.XFrameOptionsMiddleware",
]

Then I’ll use other conditional checks to see if this list (or other variables) need to be modified.

Loosely inspired by xinetd , I wrote a simple dev proxy launcher.

Currently I’m using Ansible at work, but I would MUCH rather be using Salt . A discussion on the Salt mailing list reminded me of this again, so I thought I would write down a few notes regarding why I would rather be using Salt (and why I not-so-secretly use Salt for development)

Why have both roles and playbooks?

Roles and Playbooks are somewhat similar, and feel like they have some overlap in usage, so at times it can be quite frustrating to have things that are so similar but different.