That doesn't sound quite so bad either!

I like that approach because you can add a `--url` flag to your test suite, and run those same tests against a deployed version of the project.

For projects that aren't going to see a lot of active development, I've definitely taken the shortcut of just spinning up a development server and running a basic set of tests on the final rendered pages.

I'm going to clarify the cost of a basic Fly.io deployment, but I have to wait until next week to do that.

I've been on the legacy free tier for years now, and I finally "downgraded" my account to the pay as you go plan. Kudos to Fly for honoring their free tier for years after it was deprecated!

My favorite section focuses on trust. I fully agree with this take, and this mindset is changing how I build software.

People hyping AI for profit are spilling a bunch of s**t that the rest of us have to deal with. I'm enjoying building things that center trust, explicitly against all this AI slop.

Is the volume of emails changing with the availability of ChatGPT? I'm wondering if it's absorbing some of that communication, or just encouraging people to keep going with their "theories".

OpenAI has absolutely fostered this kind of environment.

There's a whole lot of people taking all their hype at face value, who don't have the background to critically evaluate their claims.

This makes me *way* more likely to be on the latest point release, for every version, as soon as any new point release comes out.

Big takeaways: I have a bunch of interpreters (python3.14, python3.13, python3.12...python3.9) available as fast as I can type any of those aliases.

And I can update *all* of them with one command:

$ uv python upgrade

Recent releases also include a number of bug fixes. Docs are here:

py-bugger.readthedocs.io/en/latest/

This will be even more true as the project continues to evolve, and becomes capable of introducing a wider range of bugs.

The `--exception-type` argument is really helpful for teaching and learning. But in the real world, we don't know what kinds of bugs are going to appear.

Letting py-bugger randomly choose the bug that gets introduced makes your debugging practice closer to real-world debugging experiences.

The next bit of work is to make the `--exception-type` argument optional. A bare call will randomly choose the kind of error to insert. That will open up implementation of a much wider range of bugs that can be introduced.