For my personal GitHub profile, I list my activities, affiliations, and the latest updates from some of my projects.

Historically, I have used JasonEtco/rss-to-readme GitHub Action to fetch a few RSS feeds or two and to update my README a few times a day.

Overall, I’m happy with this setup. I used it on the Django News GitHub Organization to pull in newsletter issues, jobs, and the latest videos from our various projects. When I tried to install rss-to-readme in our repo, I was getting node12 errors. (Have I mentioned how much I loathe node/npm?).

Instead of forking rss-to-readme and trying to figure out how to upgrade it, I used this as an excuse to “pair program” with Claude. We quickly built out a prototype using Python and the feedparser library.

I would share the chat log, but it’s mostly me trying out a few different ways to invoke it before I settle on the finished approach. See the source code over on GitHub if you are curious: https://github.com/django-news/.github/blob/main/fetch-rss.py

Once I had a working Python script that could fetch an RSS file and modify the README, I decided to run/deploy it using UV to see how minimal I could build out the GitHub Action.

GitHub Action

To run our fetch-rss.py script, we have four steps:

1. actions/checkout Get a git checkout of our project.
2. astral-sh/setup-uv Setup UV also installs Pythons for us. As a bonus, we enabled UV’s cache support, which will run much faster in the future unless we change something in our fetch-rss.py file.
3. Run uv run fetch-rss.py ... to fetch our RSS feeds and write them to disk. uv run installs any dependencies and caches them before our fetch-rss.py runs.
4. stefanzweifel/git-auto-commit-action If our README.md file has changed, save our changes and commit them back to git and into our README.

Our schedule.yml GitHub Action workflow runs twice daily or whenever we push a new change to our repo. We also set workflow_dispatch, which gives us a button to run the script manually.

# .github/workflows/schedule.yml
name: Update README

on:
  push:
    branches:
      - main
  schedule:
    # Once a day at 12 AM
    - cron: 0 12 * * *
  workflow_dispatch:

jobs:
  update:
    runs-on: ubuntu-latest

    permissions:
      contents: write

    steps:
      - uses: actions/checkout@v4

      - name: Install uv
        uses: astral-sh/setup-uv@v3
        with:
          enable-cache: true
          cache-dependency-glob: |
                        *.py

      - name: Fetch our Feeds
        run: |
          # Fetch latest Django News Newsletter entries
          uv run fetch-rss.py \
              --section=news \
              --readme-path=profile/README.md \
              https://django-news.com/issues.rss          

      - uses: stefanzweifel/git-auto-commit-action@v5
        with:
          commit_message: ":pencil: Updates README"

Results

Overall, I’m pleased with this solution. If I wanted to spend more time on it or re-use this workflow, I might turn it into a GitHub Action workflow so that we can call: django-news/rss-to-readme to use in other projects. For now, this is fine.

I’m happy with the astral-sh/setup-uv and uv run steps because they save me from having to set up Python and then install our project dependencies as separate steps.

I normally shy away from running Python workflows like this in GitHub Actions because they involve a lot of slow steps. This entire workflow takes 16 to 20 seconds to run, which feels fast to me.

I have written quite a bit about UV on my micro blog, and I am happy to see more and more people adopt it. I have stumbled on so many good articles recently that I wanted to share them because every article points out something new or different about why UV works well for them.

If you are new to UV, it’s a new tool written by Astral, the creators of Ruff.

I like UV because it replaces, combines, or complements a bunch of Python tools into one tool and user developer experience without forcing a UV way of doing it. UV effectively solves the question, “Why do I need another Python tool?” to do everyday Python tasks.

Some reason I like UV after using it for months:

• It’s a faster pip and is really, really fast
• It can install and manage Python versions
• It can run and install Python scripts
• It can run single-file Python scripts along with their dependencies
• It can handle project lock files

While some people don’t care about UV being fast, it’s shaved minutes off my CI builds and container rebuilds, which means it has also saved me money and energy resources.

Overall thoughts on UV

Oliver Andrich’s UV — I am (somewhat) sold takes the approach of only using UV to set up a new Python environment. Oliver uses UV to install Python, aliases to call Python, and UV tool install to set up a few global utilities.

Using UV with Django

Anže Pečar’s UV with Django shows how to use UV to set up a new project with Django.

Switching from pyenv to UV

Will Guaraldi Kahn-Greene’s Switching from pyenv to uv was relatable for me because I also use pyenv, but I plan to slowly migrate to using only UV. I’m already halfway there, but I will have pyenv for my legacy projects for years because many aren’t worth porting yet.

Using UV and managing with Ansible

Adam Johnson’s Python: my new uv setup for development taught me to use uv cache prune to clean up unused cache entries and shows how he manages his UV setup using Ansible.

Some notes on UV

Simon Willison’s Notes on UV is an excellent summary of Oliver’s notes.

A parting UV tip

If you are a pre-commit fan hoping for a version that supports UV, the pre-commit-uv project does just that. I started updating my justfile recipes to bake just lint to the following uv run command, which speeds up running and installing pre-commit significantly.

$ uv run --with pre-commit-uv pre-commit run --all-files
pre-commit-uv

If you are attending DjangoCon US…

If you are attending DjangoCon US and want to talk UV, Django, Django News, Django Packages, hit me up while you are there.

I’ll be attending, volunteering, organizing, sponsoring, and sprinting around the venue in Durham, NC, for the next week starting this Friday.

We still have online and in-person tickets, but not much longer!

Brian Okken posted and published his Top pytest Plugins script and then a follow-up post, Finding the top pytest plugins, which was pretty cool.

I have written a few throw-away scripts, which William Vincent wrote about and updated a few times in the Top 10 Django Third-Party Packages (2024) and The 10 Most-Used Django Packages (2024).

These efforts are powered by Hugo van Kemenade’s excellent Top PyPI Packages.

This inspired me to fork Brian’s top-pytest-plugins project, which I updated to support passing in other package names like “django” to get a rough estimate of monthly package downloads.

The refactored project is jefftriplett/top-python-packages.

Please note: Looking at the package name doesn’t scale as well for projects that have their own Trove classifiers. For a project like pytest, it works well. Many of the top packages may not even have Django in their name for a project like Django. Some projects may even actively discourage a project from using their project in their package’s name for trademark reasons. So, YMMV applies here.

Prompts

I added uv run support, which I have written about a lot lately.

I also copied the top_pytest.py file into a Claude 3.5 Sonnet session, and I let it handle the whole refactor. It even handled adding the PEP 723 new package dependencies without me asking it to.

In case it’s useful to anyone, here are my prompts:

## Prompt:
Please update this script to use a rich table.


## Prompt:
Please update the table styles to be ascii so I can copy and paste it into a markdown doc


## Prompt:
Please remove the description column


## Prompt:
Please change all PyTest and pytest references to Django and django


## Prompt:
Please add back `if 'django' in project.lower() and 'django' != project.lower():`


## Prompt:
please remove the \*# Export to markdown section. I can just pipe the output \*


## Prompt:
Please add the typer library.


## Prompt:
Please remove days and limit


## Prompt:
Please refactor the script to allow me to pass the package name instead of django. You can default to django though.


This way I can pass pytest or flask or other projects.


## Prompt:
Please change the default Table box type to MARKDOWN

Outro

I don’t usually write about Claude or prompts, but the tool has been handy lately.

If you have had some similar successes, let me know. I have been exploring some rabbit holes, and it’s changing the way I approach solving problems.

I wanted to know how hard it would be to turn one of my django-startproject projects into a uv run friendly project. As it turns out, it worked, and the steps were more than reasonable.

Before the PEP 723’ing…

I started with a fairly vanilla manage.py that Django will give you after running python -m manage startproject.

"""Django's command-line utility for administrative tasks."""

import os
import sys


def main():
    """Run administrative tasks."""
    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "config.settings")
    try:
        from django.core.management import execute_from_command_line
    except ImportError as exc:
        raise ImportError(
            "Couldn't import Django. Are you sure it's installed and "
            "available on your PYTHONPATH environment variable? Did you "
            "forget to activate a virtual environment?"
        ) from exc
    execute_from_command_line(sys.argv)


if __name__ == "__main__":
    main()

shebang

Then we add #!/usr/bin/env -S uv run to the top of our manage.py file.

Next, we make our manage.py executable and try to run it.

$ chmod +x manage.py
$ ./manage.py
ModuleNotFoundError: No module named 'django'

Our script ran, but Python couldn’t find Django. To tell our script to install Django, we can use uv add—- script to add it.

$ uv add --script manage.py django
Updated `manage.py`
$ ./manage.py
...

Type 'manage.py help <subcommand>' for help on a specific subcommand.

Available subcommands:

[django]
    check
    compilemessages
    createcachetable
    dbshell
    diffsettings
    dumpdata
    flush
    inspectdb
    loaddata
    makemessages
    makemigrations
    migrate
    optimizemigration
    runserver
    sendtestemail
    shell
    showmigrations
    sqlflush
    sqlmigrate
    sqlsequencereset
    squashmigrations
    startapp
    startproject
    test
    testserver
Note that only Django core commands are listed as settings are not properly configured (error: No module named 'environs').

Django worked as expected this time, but Python could not find a few third-party libraries I like to include in my projects.

To add these, I passed the other four to uv add --script which will add them to the project.

$ uv add --script manage.py django-click "environs[django]" psycopg2-binary whitenoise
Updated `manage.py`
...
$ ./manage.py
...

Our Django app’s manage.py works when we run it.

After the PEP 723’ing…

After we installed our dependencies in our manage.py file, they were added to the top of the file between the /// blocks.

#!/usr/bin/env -S uv run
# /// script
# requires-python = ">=3.10"
# dependencies = [
#     "django",
#     "django-click",
#     "environs[django]",
#     "psycopg2-binary",
#     "whitenoise",
# ]
# ///
"""Django's command-line utility for administrative tasks."""

import os
import sys


def main():
    """Run administrative tasks."""
    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "config.settings")
    try:
        from django.core.management import execute_from_command_line
    except ImportError as exc:
        raise ImportError(
            "Couldn't import Django. Are you sure it's installed and "
            "available on your PYTHONPATH environment variable? Did you "
            "forget to activate a virtual environment?"
        ) from exc
    execute_from_command_line(sys.argv)


if __name__ == "__main__":
    main()