DEV Community: Christopher Hicks

How Rust Had to Save Python From Itself: The uv Revolution

Christopher Hicks — Thu, 21 May 2026 16:31:51 +0000

Well, well, well. Here we are in 2025 and Python packaging has finally been fixed. Not by the Python community, mind you - they had their shot for about 20 years. No, it took the Rust folks to come in and show us how it's done.

The Long, Painful History

Let me paint you a picture. Back when I was starting out, we had distutils. That was it. Then came setuptools, which was supposed to fix everything. Then pip showed up to handle installation. Then virtualenv because global package installs were a nightmare. Then pipenv to combine pip and virtualenv. Then poetry because pipenv wasn't quite right. Then pip-tools for deterministic builds. Then conda for scientific computing. Then...

You get the idea. Each tool solved one specific problem while creating three new ones. The Python community spent decades bikeshedding over package formats, dependency resolution algorithms, and lock file formats while the rest of the world just wanted to install packages without breaking their system. Some tools even managed to break the ancient Unix standard of shebang lines - you know, that #!/usr/bin/env python thing that's been working since the dawn of time.

The Delusion

Here's the thing that drives me nuts: the Python community kept insisting they could solve this from within. "We just need better standards!" they'd cry. "PEP 517 will fix everything!" Narrator: it didn't. "PEP 621 is the answer!" Still waiting on that revolution.

Meanwhile, every other modern language figured this out ages ago. Cargo for Rust. Go modules. npm (despite its flaws) for JavaScript. Even Perl got CPAN right decades ago! But Python? Python kept spawning new tools that partially solved the problem while maintaining backward compatibility with decades of technical debt.

Enter uv: Rust to the Rescue

Then along comes Astral with uv, written in Rust, and suddenly everything just... works. It's fast. Like, stupidly fast. It handles virtual environments transparently. It resolves dependencies without making you wait for your coffee to brew. It installs packages so quickly you wonder if it actually did anything.

The best part? They didn't try to be compatible with every broken decision the Python packaging ecosystem made over the past two decades. They looked at what actually needed to be solved and built a tool that solves those problems.

The Irony

The delicious irony here is that it took a systems programming language to fix a scripting language's package management. Rust's obsession with memory safety and performance optimization turns out to be exactly what Python's packaging ecosystem needed. Who could have predicted that?

It's like watching someone struggle to open a jar for 20 years, refusing help from anyone, only to have their neighbor walk over with the right tool and pop it open in two seconds.

What This Means

For those of us who've been dealing with Python packaging hell since the easy_install days, uv feels like a miracle. One tool that does everything, does it fast, and doesn't break when you look at it sideways. Release engineers everywhere can finally sleep soundly knowing their builds won't randomly break because of dependency resolution conflicts or virtual environment corruption.

The Python community should probably feel a little embarrassed about this. Twenty years of "we can fix this ourselves" only to be shown up by a tool written in a different language entirely. But hey, at least we finally have something that works.

So here's to the Rust community for doing what the Python community couldn't: fixing Python packaging. Sometimes you need an outsider's perspective to see the forest for the trees. Or in this case, to see the solution through all the PEPs.

Now if you'll excuse me, I need to go update all my projects to use uv. It only takes about 30 seconds per project, which is another miracle in itself. The best part? My colleagues independently discovered uv around the same time I did - that's how you know a tool is genuinely solving real problems when multiple people stumble across it organically.

Announcing gh-observer: Waiting for CI Should Not Be Misery

Christopher Hicks — Fri, 15 May 2026 07:00:00 +0000

Look, I know what you're thinking: "Another dev scratched their own itch and now they want to tell me about it." Guilty. But hear me out, because this particular itch has probably been annoying you too, and the scratch is genuinely useful.

The Problem Nobody Talks About

Here's the scenario that broke me: I push a PR, immediately run gh pr checks --watch, and... it bombs out with an error because GitHub Actions hasn't queued anything yet. So I wait. I run it again. Maybe it works, maybe it doesn't. And when it finally does start showing me checks, I'm staring at a list of job names with no idea whether that 3m 52s I've been waiting is normal or a sign that something's silently wedged.

The standard gh pr checks --watch has had some real gaps for a while now:

It doesn't handle startup delay. GitHub Actions typically takes 30-900 seconds to queue jobs after a PR is created or pushed to. The built-in watcher just... gives up during that window.
No queue latency visibility. You can see a job is "in progress," but you have no idea if it's been sitting in a queue for 2 seconds or 45 seconds before it started.
No runtime metrics. Is that job that's been "running" for a while actually running, or has GitHub just not updated the status yet? Who knows!

So naturally, I did what any reasonable developer does when something annoys them enough: I spent way more time building a solution than I would have lost just dealing with the annoyance. Classic.

Introducing gh-observer

gh-observer is a GitHub CLI extension that replaces gh pr checks --watch with something that actually tells you what's going on. It's a full TUI (terminal UI) that polls GitHub's API every 5 seconds and shows you the information you actually care about.

Here's what a typical run looks like:

PR #5: 🔶 [claude] /init 21:04:15 UTC
Updated 0s ago  •  Pushed 43h 8m 11s ago

Startup   Workflow/Job                                Duration

  15s ✗ MarkdownLint / lint                             5s
   .github:13 - Failed with exit code: 1

  15s ✓ Auto Assign / run                               5s
  15s ✓ CUE Validation / verify                         6s
  15s ✓ Checkov / scan                                 27s
  15s ✓ Claude Code Review / claude-review          3m 52s
  15s ✓ Lint GitHub Actions workflows / actionlint      8s
  39s ✓ Checkov                                         2s

Press q to quit

That 15s in the Startup column? That's how long GitHub sat on the job before actually starting it. The 3m 52s at the end? That's the total runtime. Now you know the Claude review is just slow, not broken.

The Startup Phase Thing

This is the part I'm most proud of, honestly. Instead of bombing out when there are no checks yet, gh-observer shows you a helpful waiting message:

PR #123: Add new feature

Startup Phase (37s elapsed):
  ⏳ Waiting for Actions to start...
  💡 GitHub typically takes 30-90s to queue jobs after PR creation

It tracks how long you've been waiting, reminds you that this is normal, and just... keeps watching. No manual intervention required. No re-running the command. It transitions smoothly into showing actual check status once jobs start appearing.

Features Worth Knowing About

Queue latency and runtime metrics are the headline features, but there's more:

Workflow/Job naming — Instead of just the job name, you see "MarkdownLint / lint" so you know which workflow the job belongs to. Uses GitHub's GraphQL API to pull this efficiently in a single query.
Error log integration — Failed checks show the first line of their error output right there in the terminal. No more clicking through to GitHub to find out why something failed.
Rate limit awareness — When you're getting close to GitHub API limits, it automatically backs off and polls less frequently. Keeps your rate limit healthy without any manual configuration.
CI-friendly snapshot mode — When stdout isn't a TTY (like in a script or pipeline), it prints a plain text snapshot and exits with an appropriate exit code. So gh-observer && deploy.sh actually works.
Configurable colors — ANSI 256-color support via ~/.config/gh-observer/config.yaml if you're particular about your terminal aesthetics.

Installation

The easiest path is the precompiled binary via GitHub CLI extensions — no Go
toolchain required:

gh extension install fini-net/gh-observer

Precompiled binaries exist for macOS (Intel and Apple Silicon), Linux (x86-64
and ARM64), and Windows (x86-64). All binaries include build attestations for
supply chain security verification.

How to Use It

Auto-detect your current branch's PR:

gh observer

Watch a specific PR number:

gh observer 123

Under the Hood (for the curious)

It's built in Go using Bubbletea for the TUI, which follows the Elm Architecture pattern — if you've done any Elm or Redux, the Model/Update/View pattern will feel familiar. Lipgloss handles the terminal styling.

The interesting bit technically is that it uses GitHub's GraphQL API to pull check run data — same approach as gh pr checks, but in a single query that returns both the workflow name and the job status together. This is why it can show "MarkdownLint / lint" instead of just "lint": it's joining the workflow and job name in one efficient API call.

Queue latency is calculated as the delta between when you pushed the commit and when the check actually started. Runtime is time.Now() - check.StartedAt for in-progress checks. Simple math, but surprisingly useful information.

The Code

Everything's at fini-net/gh-observer. It's open source, and I'm genuinely interested in feedback and contributions. If you hit a weird edge case or have a feature idea, open an issue.

And yes, before you ask — gh observer was partially built using gh observer to watch its own CI. It's turtles all the way down. Or the dog food tastes great. Pick your own adventure.

If you find it useful, a star on the repo goes a long way. And if you find a
bug, please do tell me so we can fix it rather than quietly suffering.