Live data from Hacker News

Fun with uv and PEP 723

cottongeeks.com

31–40 of 231 posts

Re: Fun with uv and PEP 723

#31
post #6

Earlier quoted context omitted.

Truly. uv somehow resolves and installs dependencies more quickly than pyenv manages to print its own --help output.

I know there are real reasons for slow Python startup time, with every new import having to examine swaths of filesystem paths to resolve itself, but it really is a noticeable breath of fresh air working with tools implemented in Go or Rust that have sub-ms startup.

Not to derail the Python speed hate train but pyenv is written in bash.

It's a tool for installing different versions of Python, it would be weird for it to assume it already had one available.

Re: Fun with uv and PEP 723

#34
Very nice, I believe Rust is doing something similar too which is where I initially learned of this idea of single-file shell-type scripts in other languages (with dependency management included, which is how it differs from existing ways of writing single-file scripts in e.g. scripting languages) [0].

Hopefully more languages follow suit on this pattern as it can be extremely useful for many cases, such as passing gists around, writing small programs which might otherwise be written in shell scripts, etc.

[0] https://rust-lang.github.io/rfcs/3424-cargo-script.html

Re: Fun with uv and PEP 723

#35
I like uv run and uvx like the swiss army knifes of python that they are, but PEP 723 stuff I think is mostly just a gimmick. I'm not convinced it's more than a cool trick.

Re: Fun with uv and PEP 723

#36

Does this create a separate environment for each script? If so, won't that create lots of bloat?

Yes, it creates a separate environment for each script. No, it doesn’t create a lot of bloat. There’s a separate cache and the packages are hard-linked into the environments, so it’s extremely fast and efficient.

Re: Fun with uv and PEP 723

#37

finally feels like Python scripts can Just Work™ without a virtualenv scavenger hunt. Now if only someone could do the same for shell scripts. Packaging, dependency management, and reproducibility in shell land are still stuck in the Stone Ages. Right now it’s still curl | bash and hope for the best, or a README with 12 manual steps and three missing dependencies. Sure, there’s Nix... if you’ve already transcended ti…

I use Nix for this with resholve and I like it a lot.

Re: Fun with uv and PEP 723

#38

There has been a flurry of `uv` posts on HN recently. I don't have any experience with it, is it really the future, or is it a fad? As Ive gotten older I've grown weary of third party tools, and almost always try to stick with the first party built in methods for a given task. Does uv provide enough benefit to make me reconsider?

It is difficult to use Python for utility scripts on the average Linux machine. Deploying Python projects almost require using a container. Popular distros try managing Python packages through the standard package manager rather than pip but not all packages are readily available. Sometimes you're limited by Python version and it can be non-trivial to have multiple versions installed at once. Python packaging has become a shit show.

If you use anything outside the standard library the only reliable way to run a script is installing it in a virtual environment. Doing that manually is a hassle and pyenv can be stupidly slow and wastes disk space.

With uv it's fast and easy to set up throw away venvs or run utility scripts with their dependencies easily. With the PEP-723 scheme in the linked article running a utility script is even easier since its dependencies are self-declared and a virtual environment is automatically managed. It makes using Python for system scripting/utilities practical and helps deploy larger projects.

Re: Fun with uv and PEP 723

#39
There's no lockfile or anything with this approach right? So in a year or two all of these scripts will be broken because people didn't pin their dependencies?

I like it though. It's very convenient.

Re: Fun with uv and PEP 723

#40
post #39

There's no lockfile or anything with this approach right? So in a year or two all of these scripts will be broken because people didn't pin their dependencies? I like it though. It's very convenient.

PEP 723 allows you to specify version numbers for direct dependencies, but of course indirect dependencies aren't guaranteed to be the same.
Post reply on HN