(Translation of my Japanese article on Zenn.)
This is part 4 of a series where I keep delegating implementation to AI without being able to read the code, building a vulnerability triage CLI called triage-lens. This installment is about distribution rather than the tool's internals: the tool had been sitting on GitHub, and I published it to PyPI so a single pip install triage-lens brings it in.
A confession first. Shipping took more nerve than any of the feature work did. And three "leaks" actually turned up right before release.
From the installing side to the installed side
I can't read code, but I have typed pip install before. Years ago I dabbled in Python out of curiosity, and the one thing that stuck was the experience of a useful tool arriving in one line. Now that I'm the one publishing, the other side of that one line finally became concrete. Someone builds a thing, shapes it into a package, and puts it on the public shelf called PyPI. That's why it installs in one line anywhere in the world. My turn to put something on the shelf.
I delegated the release work to AI too: package metadata, the release workflow, and one thing I insisted on. Instead of an API token, authentication to PyPI uses Trusted Publishing (OIDC). Nothing like a long-lived password gets stored anywhere; you declare "trust publishes from this workflow in this GitHub repository" and that's it. A secret you never hold is a secret that can't leak.
The pre-release check caught three real ones
In this project, nothing goes out to a public repository without passing a mechanical check. Procedures and tests, not eyeballs, verify that no personal or development-only information is mixed in. For three releases it came up empty. That's what insurance looks like.
On the fourth run it caught something real. Three somethings.
First, test code had slipped into the distribution. The packaging tool's default behavior had a path where the whole development test suite gets bundled along. I was about to scatter files nobody needs into users' environments.
The second one scared me. The name of my private development repository was about to appear in a published artifact. I run this whole activity anonymously, and keeping the development side separate from the public face is a design I care about. That boundary nearly got crossed. The funny part is how it got in: the test that checks whether the dev repository name has leaked had that very name hardcoded in its own source, so the check itself was the source of the leak. Building a check doesn't make you safe. The check is something to distrust too.
The third was mundane: relative links in the README turn into 404s on the PyPI page. Links that work on GitHub break when displayed somewhere else.
All three were fixed before release and never went out. The point I want to make is not "that was close." It's the opposite. A fixed procedure calmly caught things eyeballs would have missed. The value of turning verification into a mechanism shows up on the fourth run, after three swings at nothing.
Traps waited after the publish button too
It didn't end with a clean release. Two lessons came after publishing.
One: the description shown on the PyPI page is baked into the artifact at the moment you publish. Fix the README on GitHub afterward and the published version's page never changes. I had scheduled the README update for "after the release succeeds," so the page right after launch showed stale instructions. I ended up shipping v0.4.1, identical in content down to the last character, just to line the page up. That lesson became one more line on the pre-release checklist.
Two: the post-release smoke check failed with "that version does not exist." Not the tool's fault, not a config mistake. PyPI takes time to propagate; the dashboard showed the release while pip couldn't see it for a few dozen seconds. One more line on the checklist: confirm the new version is visible to pip before running the check.
Distribution turned out to be a pile of small traps like these. None fatal. All of them unknown to me until I tried.
It doesn't feel real yet
A night after publishing, honestly: it doesn't feel real. Anyone in the world can now install it in one line. But "can install" is not "is installing."
Whether this tool is useful will show up from here on as download counts, quantitative and merciless. I've already built weekly automation that collects article reactions and package usage. The zeros might just keep lining up. Recording that too is what this series is for, so when the numbers come in, good or bad, I'll write them up.
The repository is public. pip install triage-lens gets you in.
Top comments (0)