tldr: PEP 723 – Inline script metadata is a huge success. uv’s implementation of it, and exclude-newer tool extension is the cherry on-top. Everyone should give themselves a pat on the back!
Yesterday we had a script that was having problems. Went to debug, and of course I hadn’t written down the dependencies and never did have an environment for it. Before 723 this would be a chore. But now, this is easy!
So easy! And I’m not the only one. I frequent hackernews, and in years past the mood on python dependencies was so-so. In this recent thread, I was really happy to see these kind of comments:
With the advent of uv, I’m finally feeling like Python packaging is solved. As mentioned in the article, being able to have inline dependencies in a single-file Python script and running it naturally is just beautiful.
this (inline dependencies + uv’s exclude-newer) has also let me easily reconstruct some older environments in less than a minute, when I’ve been version hunting for 30-60 minutes in the past
I find this feature amazing for one-off scripts. It’s removing a cognitive burden I was unconsciously ignoring.
It’s worth mentioning that pipx and pip-run also implement PEP 723, but I agree that uv is the tool that seems to have brought it to people’s attention.
As another very happy user of PEP 723, I want to share the sentiment. A massive thank you to everyone who made it possible. I used to try very hard to stick to standard library for standalone scripts but that worry is now a thing of the past!
This is the kind of innovative and obviously useful extension that I pictured when I argued that we should stick to the successful patterns of pyproject.toml, rather than invent yet another one. I’m glad it’s paying off.
I also want to pile on the praise. Thank you to everyone involved! The combination of uv that will install Python, PEP 723 to specify dependencies, and mise-en-place to install uv means I can put a Python script in a golang project and have my teammates actually use it
Kinda interesting, searching for pipx 723 on DDG or Google only got me results for an issue with someone talking about removing support for 723 until it was accepted.
I keep on forgetting what 723 is even called. Properly searching for “inline script metadata” got me to this github issue where people are saying “we need to document it more”.
Anyways, I guess it’s probably worth saying “inline script metadata” out loud a lot to help the computers put everything together?
Anyways, this is yet another “723 has made me very happy” post. Being able to post minimal reproductions as single files makes it a lot easier to share concerns with certain things.
I agree, it’s really useful, and the most important part is the adoption among the packaging tools.
For years I have always fallen back - when writing some small reusable scripts - to bash and the main reason was “very soon, what is in the standard library wil not be enough and I will have to add some dependency, so how to make it easy to run by others?” And then I usually got into a trap that I was the only one who could understand what those bash scripts were doing.
That was one of the reason when I converted the development environment for Airlfow (we call it breeze as “it’s a breeze to develop airflow”) from bash years ago, when it became really unmaintainable - we had to first create an internal editable project and install it locally and that added quite a lot of friction that we had to solve (though pipx and uv tool made it very usable)
But with PEP-732 Not any more for those smaller scripts - you can have a bunch of independent, small scripts that just work, want coloured output, add rich as inline dependency. Want to parse yaml file - add pyyaml and so on. And with uv automated python installation, and no need to have Python and venv managed by the users who just run the script, it’s short of magical experience.
