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

Posted by thisdavej@reddit | Python | View on Reddit | 36 comments

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@reddit

UV is terrific. But this post doesn’t reveal any thing new 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@reddit

Why is uv terrific?

[-]

SeveralKnapkins@reddit

Easy and fast

[-]

judasthetoxic@reddit

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

[-]

average_yogi@reddit

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.

[-]

SeveralKnapkins@reddit

Hahah very fair!

[-]

Haunting_Wind1000@reddit

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

[-]

jjrreett@reddit

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.

[-]

ArtOfWarfare@reddit

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@reddit

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@reddit

Because right now the steps are:

Install Python.
python -m pip install -r requirements.txt
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@reddit

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@reddit

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.

[-]

echanuda@reddit

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.

[-]

telesonico@reddit

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

[-]

ftmprstsaaimol2@reddit

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.

[-]

AdInfinite1760@reddit

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@reddit

what makes this better?

[-]

AdInfinite1760@reddit

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@reddit

How is managing dependencies horrible in python?

[-]

echanuda@reddit

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@reddit

So you’d rather manage bash dependencies, then?

[-]

AdInfinite1760@reddit

you did not read my comment

[-]

echanuda@reddit

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 post 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.

[-]

snildeben@reddit

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

[-]

thisdavej@reddit (OP)

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.

[-]

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

It was in the 1.4.2 release.

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

[-]

cgoldberg@reddit

pipx run ./script.py

where script.py has inline dependencies declared.

[-]

South_Plant_7876@reddit

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