Live data from Hacker News

Self-contained Python scripts with uv

blog.dusktreader.dev

81–90 of 114 posts

Re: Self-contained Python scripts with uv

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

Re: Self-contained Python scripts with uv

#82

Earlier quoted context omitted.

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 ' cannot be used with '--dev' Usage: uv add --script --link-mode > 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 devel…

Interesting about the --deb flag not working with scripts. I wrote this from memory and feel like I've installed dev dependencies for a script, but it must be a hallucination because I just tried and it doesn't work. Thanks for the correction.

Aside: angle brackets should be avoided in shell examples; one mistaken enter and work can be destroyed.

Re: Self-contained Python scripts with uv

#83
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

Re: Self-contained Python scripts with uv

#84
post #51

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 curl…

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

Re: Self-contained Python scripts with uv

#85
post #48

Earlier quoted context omitted.

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?: im…

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

What is the problem with that? I see no reason to expect that would work.

Re: Self-contained Python scripts with uv

#86

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 t…

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

Re: Self-contained Python scripts with uv

#87
post #3

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.

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…

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

Re: Self-contained Python scripts with uv

#88
post #68

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

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

Re: Self-contained Python scripts with uv

#90

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

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

Post reply on HN