Self-contained Python scripts with uv

http://blog.dusktreader.dev/2025/03/29/self-contained-python-scripts-with-uv/

by todsacerdoti • 1 year ago

356 108 1 year ago

blog.dusktreader.dev

holysoles• 1 year ago

This seems like a good packaging alternative to containerizing for smaller utilities. Now to convince all my coworkers to install uv..

tiltowait2• 1 year ago

The showstopper for us is our SCA vulnerability scanner doesn't work with uv yet :(

cmgbhm• 1 year ago

You can add an intermediate sca stage that exports the uv dependencies as requirements.txt

throwaway484762• 1 year ago

Uv is amazingly fast. That should help.

dharmab2• 1 year ago

Has anyone gotten this to work on Windows? I wanted to use this trick for some tooling for a game mod I'm working on but couldn't get the shebang trick to work.

seabrookmx• 1 year ago

I haven't done dev on windows in many years, but IIRC windows doesn't have shebang support.

magicalhippo• 1 year ago

But it does support registering extension handlers[1], so if you name your scripts with say .pyuv and register "uv run --script %1", or whatever it would take to run uv, as the handler of .pyuv files, it should work. Unless uv does something funky that is.

You could do this during an installation step, for example.

[1] https://learn.microsoft.com/en-us/windows/win32/shell/fa-fil...

_mlbt• 1 year ago

You could always use something like PyInstaller...

https://pyinstaller.org

quickslowdown2• 1 year ago

I use this frequently on Windows and Linux. These are the steps I take:

$> uv init --script <script_name>.py

$> uv add --script <script_name>.py <pkg1> <pkg2> ...

$> uv add --script <script_name>.py --dev <dev_pkg1> <dev_pkg2> ...

$> uv run <script_name>.py

Hope this helps :)

Source: https://docs.astral.sh/uv/guides/scripts/

networked2• 1 year ago

Unfortunately, `uv add --dev` doesn't work with `--script`:

  > uv -V
  uv 0.6.10
  > uv add --script foo.py --dev ruff
  error: the argument '--script <SCRIPT>' cannot be used with '--dev'

  Usage: uv add --script <SCRIPT> --link-mode <LINK_MODE> <PACKAGES|--requirements <REQUIREMENTS>>

  For more information, try '--help'.

There is currently no mention of `uv add --script foo.py --dev ...` in https://docs.astral.sh/uv/guides/scripts/. Inline script metadata in Python doesn't standardize development dependencies.

I wrote a recent comment about how I develop scripts with `pyproject.toml` to have a regular development environment: https://news.ycombinator.com/item?id=43503171.

sorenjan3• 1 year ago

The regular CPython installer on Windows installs the py launcher and associates it with .py files. The py launcher supports shebang lines.

This was covered in a blog post about this same topic that was posted here a few days ago. According to that you have to omit the -S: https://thisdavej.com/share-python-scripts-like-a-pro-uv-and...

https://news.ycombinator.com/item?id=43500124

I haven't tried it myself, I simply changed the file association so all .py files are opened with uv run as standard.

https://docs.python.org/3/using/windows.html#python-launcher...

https://peps.python.org/pep-0397/

dharmab2• 1 year ago

Interesting. The workflow I've been using skips the CPython installer and only uses uv.

skeledrew5• 1 year ago

Shebang should work fine from WSL.

gus_massa• 1 year ago

I'm not sure it's useful, but someone posted how to do a similar thing for Racket with PoweScript https://onor.io/2025/01/more-scripting-with-racket.html

icameron• 1 year ago

This looks quite useful! Is uv a safer choice to use for deploying a python based project long term? I’m referring to the anaconda rug pull that happened- using it for managing dependencies about 5 years ago, but then they changed some rules so that any of my clients who are organizations with over 200 employees are no longer free to use anaconda. They must pay a commercial license

01HNNWZ0MV43FF• 1 year ago

As I understand it, relicensing is possible when a project has a Contributor Licensing Agreement (CLA) which says that you're signing over your copyright to your contribution to the project's owners. (Who will eventually be bought out by the worst rich person you can think of - Yes, him.)

I peeked in uv's contributing guide and issues and didn't see any CLA. In PyTorch the CLA was mentioned at the top of the contributing guide.

Although, there should have been a community fork of the last FOSS version of Anaconda. That's what happened with Redis, and Redis uses a CLA: https://github.com/redis/redis/blob/unstable/CONTRIBUTING.md...

Don't ever sign a CLA, kids. Hell, only contribute to copyleft projects. We get paid too much to work for free.

throwaway484762• 1 year ago

Not having a CLA prevents relicensing but open source licenses aren't revokable anyways.

godelski• 1 year ago

uv is licensed under either MIT or Apache-2.0[0]

They can always stop developing or fork to a different license and all future work belongs under that license, but you can't back date licenses, so what exists is guaranteed Open Source. If you're super worried, you can create a fork and just keep it in sync.

But this is essentially true about any other OSS project so I wouldn't be concerned. As far as I'm aware, conda was never open sourced and had always distributed binaries.

[0] https://github.com/astral-sh/uv?tab=readme-ov-file#license

globular-toast• 1 year ago

Just because something is open source doesn't mean it will be maintained. With uv there is the slight peculiarity that it's written in Rust rather than Python. So you need to count on there being an active group of Rust devs who care about Python.

Because it uses PyPI I'm happy to use it as a package manager and dev tool. The worst that can happen is I have to switch back to pip etc. But I wouldn't use it as package runtime dependency. Use pyinstaller for that.

The use case for this kind of trick I think is developer utility scripts in repos. I wouldn't want to tie any of my personal utils to uv. If it needs dependencies I'll just make a package, which is dead easy now.

scarlehoff• 1 year ago

I think anaconda's rug pull was on the repository (you can still use packages from conda-forge for free).

uv just uses pypi, so it would be just a question of changing from uv to pip, poetry or whatever, all packages would still be coming from the same place.

tiltowait2• 1 year ago

I really like this pattern, but unfortunately I haven't been able to get it to work with my LSP (pyright, in Helix), even when running my editor via uv (`uv run hx script.py`).

I could always do `uv run --with whatever-it-is-i-need hx script.py`, but that's starting to get redundant.

mayli• 1 year ago

I have my own ugly uve script

    $ cat ~/.local/bin/uve
    #!/bin/bash
    temp=$(mktemp)
    uv export --script $1 --no-hashes > $temp
    uv run --with-requirements $temp vim $1
    unlink $temp

Hope editor could support the `uv python find --script` soon.

Galanwe2• 1 year ago

FYI, have a look at "trap .. EXIT" to defer cleanups like your unlink. It's neat cause it will run even if the script is interrupted / fails before the unlink.

kissgyorgy• 1 year ago

We do the same with Nix, the shebang line looks like this:

    #! nix-shell -i python3 -p "python312.withPackages (pkgs: [ pkgs.boto3 pkgs.click ])"

With this, the only requirement is Nix on the system, you don't even need Python to be installed!

skavi2• 1 year ago

Yup, and you can apply the same technique to any language. The obvious example is bash with all the dependencies specified, but I’ve also hacked up quick single file rust scripts using nix shebangs.

https://nixos.wiki/wiki/Nix-shell_shebang

execat• 1 year ago

How to do the same thing with `nix shell` (The flake based command) instead of `nix-shell`?

skeledrew5• 1 year ago

Maybe `#! /usr/bin/env -S nix shell `?

skavi2• 1 year ago

it is a bit more annoying: https://nix.dev/manual/nix/2.22/command-ref/new-cli/nix3-she...

skowalak• 1 year ago

While that is true, there are still lots of PyPI packages not yet packaged with nixpkgs, so this is not as universal an approach as uv.

falcor84• 1 year ago

you don't even need Python to be installed!

Note that this is exactly the case in TFA - uv takes care of installing Python ad-hoc.

Tractor8626• 1 year ago

Having Nih installed is much stronger requirement than having uv

aerzen• 1 year ago

im not sure this is true

stared4• 1 year ago

My pet peeve (in general, not specific to UV, which I genuinely appreciate) is using comment sections for controlling code execution.

Using comments for linters and developer notes is perfectly acceptable. However, for configuration or execution-related data, a far superior pattern would be something like:

  UV_ENV = {
    "dependencies": { "requests":  "2.32.3", "pandas": "2.2.3" }
  }

This approach has clear advantages:

- It's valid Python syntax.

- It utilizes standard, easily-parsable data structures rather than ad-hoc comment parsing. It makes creation and validation smooth.

- Crucially, it adheres to a core principle: if you remove all comments from your code, it should still execute identically.

petters• 1 year ago

I completely agree. Hope something like this is eventually standardized.

Problem is that uv probably does not want to execute anything to find out dependencies, so it would have to be a very restrictive subset of python syntax.

The fact that is is needed at all of course highlights a weakness in the language. The import statements themselves should be able to convey all information about dependencies

stared4• 1 year ago

It can be specified that it is a valid, static structure before imports.

pedrosorio• 1 year ago

The fact that is is needed at all of course highlights a weakness in the language. The import statements themselves should be able to convey all information about dependencies

What languages convey the version of the dependencies in a script’s import statements?

SAI_Peregrinus• 1 year ago

UV just implemented PEP 723[1], which is now PyPA Inline Script Metadata[2]. That's no longer provisional, it is standardized already! It's unfortunate that Python didn't have some non-comment way to provide this functionality.

[1] https://peps.python.org/pep-0723/

[2] https://packaging.python.org/en/latest/specifications/inline...

sorenjan3• 1 year ago

This isn't a uv invention, uv is only using the standard PEP 723 like other tools.

https://peps.python.org/pep-0723/

stared4• 1 year ago

As I mentioned, it is not criticism of uv, but of this general approach.

gorgoiler2• 1 year ago

I agree, but I would go a step further.

You’re using a magic constant that doesn’t do anything at runtime. It’s only there to be parsed by static analysis. In your case that’s uv doing the parsing but another tool might delete it as unused code. In the sense that it’s one thing pretending to be another, for me, it’s in the same category as a magic comment.

Instead, why not make a call to uv telling it what to do?:

  import uv

  uv.exec(
    dependencies=[“clown”],
    python=“>=3.10”,
  )

  from clown import nose

The first call can be with any old python runtime capable of locating this hypothetical uv package. The uv package sets up the venv and python runtime and re-exec(3)s with some kind of flag, say, an environment variable.

In the second runtime uv.exec is a noop because it detects the flag.

hanikesn• 1 year ago

There's justification for that:

https://peps.python.org/pep-0723/#why-not-use-possibly-restr...

simonw• 1 year ago

Because now your code won't run unless you have installed uv previously.

nickpsecurity• 1 year ago

" In your case that’s uv doing the parsing but another tool might delete it as unused code."

That's probably the goal. It's only there for one tool. If it's not used, we want it to have no impact on the running app. Like comments.

dagw3• 1 year ago

Instead, why not make a call to uv telling it what to do?

One important aspect to remember is that this isn't intended to be a uv specific feature. It's a (proposed) python standard feature that in the future other python package managers will implement. So whatever solution they come up with it has to work with any standard compliant package manager, not just uv.

Retr0id2• 1 year ago

Different python versions have different syntax grammars, so if the rest of your file has new syntax, and older python might not be able to execute even the first few lines.

For example if you run this on python3.6:

    print("hello")
    match 123:
        case _: pass

you won't even get a "hello".

loloquwowndueo• 1 year ago

That makes your code depend on UV where otherwise it wouldn’t.

Remember the specification to indicate dependencies in a comment on a script is a PEP (723) and it’s tool-agnostic.

skeledrew5• 1 year ago

One of uv's justifications is that it isn't dependent on Python, and so there's no circular bootstrap problem. Things are now at the point with uv were you tell the person you're sharing a script with: 1. Get the install command from the uv site and run it (if they don't already have it installed). 2. Run the script with uv.

Literally cannot get simpler than that. Making uv an importable means assuming Python is present or easily installed on every system, which if it were the case then uv wouldn't be becoming a thing.

JimDabell• 1 year ago

That’s fair. I agree with other replies though that parsing and evaluating imperative code is a lot tougher and less flexible than adhering to the principle of least power and making it declarative data.

It’s also worth noting that using comments is exactly how the shebang line works in the first place. It’s just so well-ingrained after 45 years that people don’t notice that it’s a shell comment.

Svoka• 1 year ago

I generally agree but it literally uses shebang

wavemode• 1 year ago

if you remove all comments from your code, it should still execute identically

It still -does- execute identically. Provided you install the same dependencies.

I don't see this as changing the semantics of the code itself, rather just changing the environment in which the code runs. In that respect it is no different from a `#!/bin/bash` comment at the top of a shell script.

ulrischa• 1 year ago

So now I have to make sure uv is installed instead of python. Whar us this better? And python is available on almost any system

shawabawa3• 1 year ago

The whole point of uv is to solve the nightmare that is running a script with the right version of python with the right dependencies

"Just use the system python" gets you right back to the start (oh no! It didn't parse because it used python 3.11 features and I'm still on 3.5)

mr_mitm• 1 year ago

uv can seemlessly get the correct python binary on demand. It would be a pain to get, say, python 3.9 or python 3.14 on my system. Making sure uv is installed actually seems to be less of an issue, but of course this varies.

skeledrew5• 1 year ago

Python is not a globally available thing. I was really surprised when I setup Kubuntu 24.04 and found it missing. And now you can do `uv run --python=<version> ...` and have all that automatically handled on a case by case basis.

whywhywhywhy• 1 year ago

And python is available on almost any system

This is actually the root of all Python problems, by it believing it has a right to be a core part of the operating system all the package design choices treat their installation like they're the only thing running on the machine when the realities of Python packages are they all rely on very specific versioning from the interpreter to between the packages so the idea of having a canonical version of pytorch that all your projects run on just doesn't exist.

frizlab• 1 year ago

Hey I have done the same for Swift scripts! (Well I have rewritten what Homebrew’s creator did some time ago, but does not maintain anymore, to be precise.)

https://github.com/xcode-actions/swift-sh

bityard• 1 year ago

This has come up a LOT on HN in the past few months, some other recent examples:

https://news.ycombinator.com/item?id=43500124

https://news.ycombinator.com/item?id=42463975

I like uv and all, but I take exception to the "self-contained" claim in two regards:

1) The script requires uv to already be installed. Arguably you could make it a shell script that checks if uv is already installed and then installs it via curlpipe if not... but that's quite a bit of extra boilerplate and the curlpipe pattern is already pretty gross on its own.

2) Auto-creating a venv somewhere in your home directory is not really self-contained. If you run the script as a one-off and then delete it, that venv is still there, taking up space. I can't find any assertion in the uv docs that these temporary virtual environments are ever automatically cleaned up.

benhurmarcel• 1 year ago

I can't find any assertion in the uv docs that these temporary virtual environments are ever automatically cleaned up.

That’s a good point. I wonder if at least they are reused when you run the script several times.

dagw3• 1 year ago

My understanding is that uv creates a hash of the script name, python version and dependencies when creating the venv. So if none of those change, it will reuse the venv.

maxed• 1 year ago

I took a closer look; uv installs the inline required packages in it's cache directory `~/.cache/uv` (if they are not already there). So the packages will probably exist until the cache is cleared with for example `uv clear`.

It's not that the inline requirements make a new `.venv` directory or something, uv seems to link the packages to a central location and reuse them if already there.

photonthug• 1 year ago

I tried to hack together a shebang with docker+uv to solve this kind of problem, and it sort of does because that’s maybe more common than uv for a random dev machine (especially since tfa says it’s a gong project).

This works but doesn’t cache anything so the download for every run is awkward. This can probably be fixed with a volume tho?

Something like this: https://hugojosefson.github.io/docker-shebang/#python

dazzawazza• 1 year ago

Agree 100%. Using something like py2exe creates a self contained "python script". This comes with a lot of problems for the developer but minimum problems for the user.

networked2• 1 year ago

Right, you need to have uv installed, and if you don't, you'll probably have to install it manually or through `curl | sh`. I think this is a valid complaint. Something to consider is that it will become less of an issue as package managers include uv in their repositories. For example, uv is already available in Alpine Linux and Homebrew: https://repology.org/project/uv/versions.

Another thing is that inline script metadata is a Python standard. When there is no uv on the system and uv isn't packaged but you have the right version of Python for the script, you can run the script with pipx: https://pipx.pypa.io/stable/examples/#pipx-run-examples. pipx is much more widely packaged: https://repology.org/project/pipx/versions.

Gud3• 1 year ago

curl | sh is an abhorrent practice and should never be used.

gcr• 1 year ago

A nitpick: uv’s package deduplication means virtualenvs do not take up space unless they have unique dependencies.

krupan3• 1 year ago

You usually have to install something before you can run a program on your computer, so installing uv doesn't seem that bad to me. I still wouldn't call this self-contained because when you run the program it downloads who knows what from the internet!

To me, fully self-contained is something more like an AppImage

intellectronica• 1 year ago

Even better: self-contained uv run python scripts generated by AI: https://everything.intellectronica.net/p/the-little-scripter

mos_6502• 1 year ago

Seems analogous to bundler/inline [1] on the Ruby side of the world. Happy to see something similar in Python— it’s really handy!

[1] https://bundler.io/guides/bundler_in_a_single_file_ruby_scri...

Szpadel2• 1 year ago

I do not really understand how this is self contained, when you have to install additional software to run it.

my approach is to use python build-in venv https://gist.github.com/Szpadel/43794d606d9924e7fea3e63fb800...

that way you can run scripts with external packages with only basic python installation

maleldil3• 1 year ago

Your version needs Python. uv needs needs only uv, as it can manage python installation by itself.

It's also a lot easier to install uv than to manage Python installations (there's a reason pyenv and the like exist).

Szpadel2• 1 year ago

That's fair point. Its maybe different use case. For me main goal was to be able to run project scripts on macos and Linux ootb, and both have some python 3 version already available ootb.

But probably if you need specific python version it isn't best way

northisup• 1 year ago

help get this supported in vscode by liking the issue here: https://github.com/microsoft/vscode-python/issues/24916

amelius• 1 year ago

So how does this guarantee that it will never raise some libc error, or similar? Unfortunately I have become sceptical about "self contained" distribution methods.

maxerickson• 1 year ago

This isn't self contained in that sense, it's deferring dependency management to runtime, with uv apparently doing that reliably enough for the use case.

winwang• 1 year ago

What do people think about pixi?

yallpendantools• 1 year ago

I learned to love uv because of this usecase but I still find it against the Zen of Python that an official (and, dare I say, extremely useful!) PEP is not supported by the official Python tools.

This is the first time that Python didn't come with "batteries included" from my POV.

Now I also have two Python dependency managers in my system. I know there are volumes to talk about Python dependency management but all these years, as long as a project had a requirements.txt, I managed to stick to vanilla pip+venv.

shiandow• 1 year ago

That's been a bit of a trend for the Python build specs. Pretty sure the pyproject toml predates the tomllib library. So for a few versions you had to specify your module in a language that Python couldn't read natively.

Which is worse than just having a default way for including metadata that's not used. That's what makes it metadata after all. Otherwise it would just be Python syntax

redsky880• 1 year ago

Hmmm this seems bad

That code is bad for several reasons including not catching+handling exceptions (and possibly retrying), and accessing the JSON properties w/o get()

The overhead of re-installing stuff and setting up a header seem very unnecessary to run a simple script

If this is about sending some Python for somebody else to run easily - the recipient should always check the code. You should never run arbitrary code. For example, there have been hacks performed using YAML loader (crypto exchange).

For dependencies, use the standard pyproject.toml

bitwize• 1 year ago

When Python has something akin to Tcl's starkits, then it'll be cooking with gas -- I might even use it again. Py2exe came close, but was not cross-platform.

krupan3• 1 year ago

Overall, and admittedly from a bit of a distance, uv run feels like a reinvention of Zero Install, but for only Python.

I also wondered why virtual environments were invented for Python when general environment managers (like Modules) already existed.

These packaging and environment problems have never been specific to Python

https://0install.net/ https://modules.sourceforge.net/

talideon2• 1 year ago

uv has little in common with 0install, which has its origins in RISC OS's application directories.

uv is an attempt to fix the fragments Python development environment tooling story.

krupan3• 1 year ago

I mean yes, you are correct. UV does a lot of different things, but this particular "self-contained app" feature is a lot like zero install. You run your app, its dependencies are automatically downloaded and cached for other uv/zero install apps to use, and it's all transparent and easy.

amai• 1 year ago

Ironically zero install is pretty difficult to install: https://docs.0install.net/details/macos/

egeres• 1 year ago

I love it, it feels like an extension of these other HN posts:

- Uv's killer feature is making ad-hoc environments easy (valatka.dev): https://news.ycombinator.com/item?id=42676432

- Using uv as your shebang line (akrabat.com): https://news.ycombinator.com/item?id=42855258

bheadmaster• 1 year ago

As mentioned in other comments, the "self-contained" claim depends on `uv` being installed.

For those who want a really self-contained Python script, I'd like to point out the Nuitka compiler [0]. I've been using it in production for my gRPC services with no issues whatsoever - just "nuitka --onefile run.py" and that's it. It Just Werks. And since it's a compiler, the resulting binary is even faster than the original Python program would be if it were bundled via Pyinstaller.

The author's GitHub page [1] contains the following text:

    Other than software development, my passion would be no
    other. It's my life mission to create the best Python
    Compiler I can possibly do or die trying, ... of old
    age.

[0] https://nuitka.net/

[1] https://github.com/kayhayen

Self-contained Python scripts with uv

Related Stories