HN Reader

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

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

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

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.

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

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

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

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!

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.

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/

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

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.

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.

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

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

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

What do people think about pixi?

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.

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

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.

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.