The last time I commented extolling the virtues of uv on here, I got a similar reply, pointing out that PEP 723 specs this behavior, and uv isn’t the only way. So I’ll try again in this thread: I’m bullish on uv, and waiting for Cunningham.
I am all in on uv as well, and advocating for its use heavily at $dayjob. But I think having as much as possible of these things encoded in standards is good for the ecosystem. Maybe in a few years time, someone will make something even better than uv. And in the meantime, having things standardised speeds up adoption in e.g. syntax highlighting in editors and such.
I’ve started migrating all of my ~15 years of one-off python scripts to have this front matter. Right now, I just update when/if I use them. I keep thinking if were handier with grep/sed/regex etc, I’d try to programmatically update .pys system-wide. But, many aren’t git tracked/version controlled, just laying in whatever dir they service(d). I’ve several times started a “python script dashboard” or “hacky tools coordinator” but stop when I remember most of these are unrelated (to each-other) and un/rarely used. I keep watching the chatter and thinking this is probably an easy task for codex, or some other agent but these pys are “mine” (and I knew^ how they worked when I wrote^ them) and also, they’re scattered and there’s no way I’m turning an agent loose on my file system.
^mostly, some defs might have StackOverflow copy/pasta
You could run ripgrep on your file system root to find most of them, its insanely fast, then feed it to claude or something to generate a script to do it for you.
This is an awesome features for quick development.
I'm sure the documentation of this featureset highlights what I'm about to say but if you're attracted to the simplicity of writing Python projects who are initialized using this method, do not use this code in staging/prod.
If you don't see why this is not production friendly it's for the simple a good.reaaon that creating deployable artifacts packaging a project or a dependency of a project this uses this method, creating reproducible builds becomes impossible.
This will also lead to builds that pass your CI but fail to run in their destination environment and vice versa due to the fact that they download heir dependencies on the fly.
There may be workarounds and I know nothing of this feature so investigate yourself if you must.
This isn't really "alternatively"; it's pointing out that in addition to the shebang you can add a PEP 723 dependency specification that `uv run` (like pipx, and some other tools) can take into account.
I'm actually a bit annoyed that uv won. I found pdm to be a really nice solution that fixed a lot of the issues poetry had without the hard ideological stance behind it, while fixing most of its problems. But maybe that ideology was partly what drove it's adoption.
