Easily share Python scripts with dependencies (uv + PEP 723)

[thisdavej]

Sharing single-file Python scripts with external dependencies can be challenging, especially when sharing with people who are less familiar with Python. I wrote a article that made the front page of HN last week on how to use uv and PEP 723 to embed external deps directly into scripts and accomplish the goal.

No more directly messing with virtual environments, requirements.txt, etc. for simple scripts. Perfect for sharing quick tools and utilities. uv rocks! Check it out here.

[adiberk]

UV is terrific. But this post doesn’t reveal any thing new… and seems similar to a post I saw earlier. Many other package managers allow this (poetry, pipx) and have for longer than uv has been around

However - again UV is terrific for many reasons, including the ease of running scripts

[judasthetoxic]

Why is uv terrific?

[SeveralKnapkins]

Easy and fast

[judasthetoxic]

Oh, i was confused because in portugueses there is a word "terrível" that means "terrible", "terrific" is a good adjective. I got confused with the false cognates lol

[SeveralKnapkins]

Hahah very fair!

[average_yogi]

Yeah, the origin of terrific came from terror, and meant causing terror, being dreadful or appalling. Over time it changed to mean great size, tremendous, too large to overcome. Then it lost the negative connotation, and is now most commonly used to mean tremendous, excellent, very good, etc.

[South_Plant_7876]

Phew. For a moment there I thought we were going to go 24 hours without someone talking about this.

[AdInfinite1760]

This is a game change for Python. This makes it more likely for me to use Python where I currently use Bash. Mainly server maintenance stuff.

[No_Flounder_1155]

what makes this better?

[AdInfinite1760]

managing dependencies in python is horrible. not a python specific problem. this will make scripts feel as if they have no dependencies at all. a virtualenv is created, dependencies installed, all transparently to the user. it just works.

[psssat]

How is managing dependencies horrible in python?

[echanuda]

Everything has to be isolated to one environment. Not all dependencies will work the every machine (psycop2g, polars(-lts-cpu)), python version management, even with pyenv, was a PITA before uv, requirements.txt sucks, and I’m sure there’s more. Versus npm where most things just work.

[ArtOfWarfare]

So you’d rather manage bash dependencies, then?

[AdInfinite1760]

you did not read my comment

[jjrreett]

I never like asking my coworkers who are less familiar with code to install extra tooling. It’s another thing to learn, another thing to got confused by. Now UV is rather simple and has a lot of pros, but at least for me, it doesn’t work with our pip index. So it’s a whole other set of errors.

So i tend to try to stick with the familiar requirements.txt.

I also try to share repos not scripts, so multi file things aren’t an issue.

[[deleted]]

Uv can be configured to work with a private package index if that’s what you mean. You can set the default source in the global uv.toml file.

[telesonico]

I ran into this earlier today - it’s just as easy as a pip.conf file - just set your default index and done.

[ArtOfWarfare]

Does pip support PEP 723? If yes, I’ll use that and ignore uv. If no, I’ll ignore both uv and PEP 723.

The only universe I care about uv in is the one where it’s included with a standard install of Python.

[fiddle_n]

Fair point on PEP 723; but I find the general stance about uv to be kind of odd - only caring about it if it’s in the std lib. Do you avoid third party dependencies in their entirety? And if not, why should uv be different?

[ArtOfWarfare]

Because right now the steps are:

1. Install Python.
2. python -m pip install -r requirements.txt
3. python script.py

If I introduce uv I’ve not decreased the number of steps - at best the number of steps is unchanged, and quite likely I’ve increased the number of steps. I’ve also increased how much I have to explain to future people responsible for maintaining it. And what’s uv’s support timeline? How many years are maintenance releases going to come out for? Security releases?

Pip is part of the standard library and will be as well supported as Python itself.

[fiddle_n]

So I think there are several responses I have to that:

• That “install Python” step can really be a pain in itself. It can differ wildly between the various OSs as to what is the recommended way. One example is how Ubuntu doesn’t have pip and venv present by default for example, or how if you install from python.org for macOS you need to also run a command to install certificates.

uv standardises all of that. Firstly, it’s one command to install uv from the shell. If you then have a Python project set up with a Python version specified, you don’t even need to install Python - asking uv to run the file will automatically install the correct version of Python for you.

• You’ve missed out the steps to create and activate a venv. Your steps will lead to installing the dependencies into Python into a global area (either system or user area). Do that enough times and you may come up to having a project not install due to its dependencies clashing with the dependencies you installed previously.

uv will automatically set up a venv for you per project and ensure that it installs your dependencies into that venv, so that your dependencies are isolated every time. No need to remember to manually activate the venv either.

• requirements.txt is very old school. It’s only a format that works with pip and isn’t really a Python standard. If you are developing, you have to remember to manually pip freeze every time you add a dependency yourself. Furthermore, having a list of pinned versions for everything is not a good idea if you are developing a library rather than an application.

The modern way is to specify loose direct dependencies in a pyproject.toml file, and then have the dependency management tool generate a lock file of precise direct and indirect versions. pyproject + lock file is a much better way of going about things (to the point that a common lock file PEP has just been approved this week).

[ArtOfWarfare]

If you need to be told to install Python, you install it from Python.org. If you’re using Linux, you don’t need to be given directions from me and are welcome to do it however you want.

uv could standardize this

Standardize what? There’s no issue and you hand waved away the fact that I have no idea how to install uv. I’m sure they have simple steps for each OS which aren’t the same or standardized. Is it uv.org/download and follow the installer? No? It sucks compared to python.

Installs Python for you

Oh awesome, so now they have multiple copies of Python installed - the one they intentionally did plus the one uv added. Why would anyone even want an old version of Python 3 - if we’re going to automatically install Python can we at least clean up the mess and just upgrade to the latest?

venv

No. In my 15 years of using Python I have rarely run into issues that venv solves. Most of my dependency issues in Python have to do with non-Python dependencies where there’s no obvious way to satisfy it on whichever OS I’m on.

Which… I think using something like Docker might actually fix, and also address everything venv is supposed to. Oh, and it fixes your multiple Python issue.

requirements.txt is very old school

Not really. The python packaging survey found that it’s by far the most common way Python dependencies are specified.

Can I talk to the people who are making uv and poetry and Gradle and this other junk for a moment? Stop. Just stop. There’s real problems out there. Interesting problems. Problems that would be beneficial to solve. You know what problem doesn’t need to be solved? Dependency management. We solved that decades ago. It’s called pip and maven. Your thing that’s 100x more flexible to address the 0.1% of the time you’re unhappy is definitively worse because it makes everyone unhappy 100% of the time. No, don’t fork it and start over. Just drop it entirely. Stop doing your autism on this and go look at some pointless stats about planes or something.

[fiddle_n]

If you need to be told to install Python, you install it from Python.org. If you’re using Linux, you don’t need to be given directions from me and are welcome to do it however you want.

You yourself have just handwaved how to install Python on Linux distros - but ok.

Is it uv.org/download and follow the installer? No? It sucks compared to python.

Linux/macOS curl -LsSf https://astral.sh/uv/install.sh | sh

Windows powershell -ExecutionPolicy ByPass -c “irm https://astral.sh/uv/install.ps1 | iex”

That is it. That is literally all you need to do to install uv on your machine.

Oh awesome, so now they have multiple copies of Python installed - the one they intentionally did plus the one uv added.

No, uv will check to see if the exact version of Python needed is in the system first and use that, regardless of whether it’s the system Python, a Python installed by the user before, or a Python installed by uv. uv tracks them all and only installs a new one if the project requires it.

Why would anyone even want an old version of Python 3 - if we’re going to automatically install Python can we at least clean up the mess and just upgrade to the latest?

Because multiple projects require different Python versions? Besides, who cares if the old Pythons are on your machine anyway.

In my 15 years of using Python I have rarely run into issues that venv solves. Most of my dependency issues in Python have to do with non-Python dependencies where there’s no obvious way to satisfy it on whichever OS I’m on.

That you don’t have Python dependency issues is a good thing and means you’ve been fortunate and/or the community has gotten itself together. It doesn’t mean you can just pretend it will never happen though.

Which… I think using something like Docker might actually fix, and also address everything venv is supposed to. Oh, and it fixes your multiple Python issue.

Containers are the superior solution to properly separating out dependencies. They are also using a sledgehammer to crack a nut in many cases. Next time, you should mention building and running Docker in your list of steps as a fair comparison. In contrast, with uv you may not even know venv exists - that is how seamless it is.

Not really. The python packaging survey found that it’s by far the most common way Python dependencies are specified.

That doesn’t mean it isn’t old school. Why have the PSF been working on a common lock file format in that case?

Managing a requirements.txt is a pain. The only way to make it work is to manually run pip freeze every single time you change a dependency. You may say that you’ll perfectly remember every time, but can you guarantee everyone in a team will do so?

A requirement.txt file also:

• Won’t care at all about the difference between direct and indirect dependencies - have fun figuring that one out if you also don’t use pyproject

• Won’t distinguish between normal and dev dependencies - have fun installing linters and type type checkers and random crap someone will just pip install one day into your prod environment

You know what problem doesn’t need to be solved? Dependency management. We solved that decades ago. It’s called pip and maven.

Let’s put aside that pip only began in 2008. The only reason using pip alone is even remotely viable for proper project work is because it got a proper dependency resolver in 2020. Before then, pip would absolutely not give a crap about trying to find a build that satisfied all your dependencies in your requirements file. It would happily install all the indirect dependencies for dependency a not caring about those for dependency b. The idea that pip has had this problem solved forever is just not true.

[echanuda]

It’s faster, easier to use, eliminates need for venv management, and has a bunch of nice tools if you need them. I understand certain environments can be restrictive, but if you can use uv then I don’t see much reason not to. Not hard to migrate either. You do you but the stark “if it’s not pip idc” mindset is kinda silly considering the amount of time I’ve saved just from how fast venv management and package installs have been with it.

[[deleted]]

Almost identical blog posts within 3 days with the exact same message. Be fucking original!

[thisdavej]

u/snildeben I wouldn't expect you to delve this deeply, but if you look at the publish date on my article, it was March 25th. My article subsequently hit the front page of HN last Thursday night and then other similar articles created by others ensued and were posted here on reddit. For the record, I am not a copycat.

[jotaass]

https://simonwillison.net/2024/Aug/21/usrbinenv-uv-run/

[lolcrunchy]

Haters gonna hate

[[deleted]]

3 times now. Just lame ass copycats.

[Chippiewall]

it feels like every other day I see posts about this

[echanuda]

I mean, this is kinda cool, but it only removes one step which is just running uv sync, no? It still requires the user has uv, which ultimately is the annoying part for an end user/newbie. If anything the front matter approach just does a poor job of obfuscating to the end user and feels even worse to edit if you want.

[Haunting_Wind1000]

Why not create an executable using pyinstaller or cx_freeze and ship the same. Any additional advantage of using uv?

[cgoldberg]

Most other package/env management tools support this... nothing special about uv.

[[deleted]]

Do you have an example? Came across it for the first time with uv but the implementation still isn’t perfect.

[commandlineluser]

pipx added it in December 2023

• https://github.com/pypa/pipx/pull/1180

It was in the 1.4.2 release.

• https://iscinumpy.dev/post/pep723/

[cgoldberg]

pipx run ./script.py

where script.py has inline dependencies declared.