This week's dispatches from the Ministry of Intrigue

Hello, faithful reader.

We published the following fresh dispatches this week:

The Stallman Report Is Damning

Oct. 15, 2024, 1:28 p.m.

Published on October 14, 2024, The Stallman Report is a damning review of Richard Stallman’s long history of misconduct. While it acknowledges his many contributions to the Free Software Foundation , it also makes a clear case for why he should not be permitted within its leadership.

Ignorance of the case against Stallman is due in part to the scattered and disorganized nature of information regarding Stallman’s misconduct. Many of those who raise a defense of Stallman have heard one or two uncorroborated allegations of misconduct or one or two examples of years-old problematic quotes, and understandably find it easier to excuse it as such. Furthermore, those most directly accountable for Stallman’s behavior are the members of the Free Software Foundation board of directors, and their misconduct in handling the case is not widely known; this report brings this misconduct to light. By carefully organizing information about Stallman’s misconduct and the misconduct of the FSF board of directors into a single, comprehensive and exhaustively cited report, the appeal to ignorance is no longer applicable.

This report collects hundreds of primary sources from 2003 to 2024 which clearly demonstrate Stallman’s harmful political program and misconduct, meticulously cataloged, analyzed, and subject to factual rebuttals. If the free software community cannot address the blatant misconduct of Richard Stallman in the face of overwhelming evidence, the free software community is not safe, and cannot be made safe. Our institutions and our community must act. We have made several recommendations for such actions at the end of the report.

First, we will justify our unqualified condemnation of Richard Stallman.

The report covers a wide range of issues, from outspoken defense of sexual misconduct, toxic behavior in the workplace, and frankly the chilling effect his reinstatement had on the organization.

In 2021, 61 institutions and 3,003 individuals signed an open letter calling for Stallman to be removed from all leadership positions, and calling for the board of directors of the Free Software Foundation to resign. An additional 33 GNU project maintainers and developers collectively called for Stallman’s removal in 2019.

This report highlights the following institutions that have explicitly withdrawn financial support and/or adopted a policy of non-cooperation with the Free Software Foundation over concerns regarding Richard Stallman:

• Free Software Community of India
• Free Software Foundation Europe
• Okta Bad Packets
• Outreachy
• Red Hat
• The Fedora Project
• The Open Source Initiative
• Tor Foundation
• openSUSE

I don’t know how any sane person could read this report and conclude other than Stallman needs to go.

TIL - Using pre-commit hooks with Bump My Version, pre-commit, and uv

Oct. 14, 2024, 5:10 p.m.

I’ve long been a fan of bump-my-version for updating version numbers and certain bits of documentation when getting ready to release an update to a project. I’ve also adopted uv for managing all my Python projects. However, I recently ran into an annoying snag when prepping a new version because I had the following in my .pre-commit-config.yaml :

  - repo: local
    hooks:
      - id: ruff
        name: Run ruff
        entry: uv run ruff check src/
        language: system
        files: \.py$

      - id: pyright
        name: Run pyright type checking
        entry: uv run pyright
        language: system
        files: \.py$

Since uv run by default will attempt a sync, and since bump-my-version has updated the version number, uv.lock gets updated, which throws an error for pre-commit. As far as I could tell, there were two options:

1. Use the uv run --no-sync option in the pre-commit hooks, OR
2. Make sure that the change gets included in bump-my-version ’s commit.

Option 1 means that the lock file change doesn’t get included in the tag for the release number, while Option 2 adds potential risk that some other unintended change to uv.lock gets included. After evaluating the two, and considering that I only run bump-my-version locally, I opted for the latter.

So I added the following to the [tool.bumpversion] section of pyproject.toml :

[tool.bumpversion]
# All sorts of other settings here...
# ...
allow_dirty = false
commit = true
message = "Bump version: {current_version} → {new_version}"
pre_commit_hooks = ["uv sync", "git add uv.lock"]  # The new bit.
commit_args = ""

This ensures that prior to pre-commit being run, the version update gets added to uv.lock , and it is included in the commit of changes coming from bump-my-version .

This seems to resolve my issue with the minimum amount of risk, though if you have a better way to solution for this, I would love to hear it .

All in on uv

Oct. 14, 2024, 12:38 p.m.

At this point, if you work with Python at all, you’ve assuredly heard of Astral’s uv tool, their attempt to create a “Cargo for Python”. Given the huge splash its made in the community, its not hard to see why. It’s quickly become my favorite amongst its kin.

I’ve written previously about my experiments with Rye for managing Python projects, which felt like the closest to what I had originally wanted tools like Poetry , Hatch , and their like to be. My worry with Rye was that it was a small project, and I wasn’t sure it would achieve enough momentum to become a viable contender in the long term. I also knew that its author, Armin Ronacher , had already transitioned stewardship of the tool to the folks at Astral, which, given their work on uv , suggested a limited lifespan. I was intrigued by uv , but at that point, it was only usable as a fast replacement for virtualenv and pip , so I didn’t dig much deeper.

Now, especially with the 0.3 and 0.4 releases, uv has become a full project management solution for Python. It is incredibly close, IMHO, to achieving its goal of being a universal tool ¹ , and at this point, I am all in on uv . I’ve converted all my active Python projects to use it, including all their assorted CI workflows. ² For my local development, I use it to manage my Python toolchain installations. Using companion tools like tox-uv and pre-commit-uv have also done wonders to speed up my linting, test, and type-checking runs.

I know there’s been some sturm und drang over it being managed by a VC-backed firm and that it is developed in Rust , which while popular, still has a smaller community than Python. Honestly, given the permissive license, I’m less concerned with company of origin. The issues with the Rust language community is a valid concern, but we’re already seeing a number of popular Python libraries, e.g. Pydantic , using Rust to accelerate their performance. It seems unlikely that the trend will change anytime soon, and I suspect we’ll continue to see more and more Python and Rust marriages in the future.

I’m really impressed with the tool, and am excited about the speed at which it has become adopted by the community at large. Packaging and dependency management has been a huge frustration in Python for a long time, and now I feel like we finally have a viable solution.

TIL - Use uv for Build and Publish workflows in Github Actions

Oct. 14, 2024, 11:38 a.m.

I’ve been using uv in my Github Actions workflows for a while now to speed up my runner environment creation, and I wanted to do the same for my publishing workflows. So, I created the following workflow for each of my PyPI packages.

# publish.yml

name: "Publish"

on:
  release:
    types: ["published"]

jobs:
  run:
    name: "Build and publish release"
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

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

      - name: Set up Python
        run: uv python install 3.12  # Or whatever version I want to use.

      - name: Build
        run: uv build

      - name: Publish
        run: uv publish -t $

To use it, I add a secret to the repository in the form a project-scoped PyPI token that can be referenced by the workflow. Now, whenever I publish a new release in Github, it will automatically use uv to build the wheel and sdist packages and then upload them to PyPI.

Easy!

And that's it!

Grave dust and falling leaves.