Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fun with uv and PEP 723

cottongeeks.com

Post reply on HN
Print view View original

61–70 of 231 posts

Re: Fun with uv and PEP 723

#61

Post by password4321 »

ACAVJW4H wrote: post #12

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'm unable to resist responding that clearly the solution is to run Nix in Docker as your shell since packaging, dependency management, and reproducibility will be at theoretical maximum.

Re: Fun with uv and PEP 723

#62

Post by zahlman »

0cf8612b2e1e wrote: post #23
sambaumann wrote: post #20

Between yesterday's thread and this thread I decided to finally give uv a shot today - I'm impressed, both by the speed and how easy it is to manage dependencies for a project. I think their docs could use a little bit of work, especially there should be a defined path to switch from a requirements.txt based workflow to uv. Also I felt like it's a little confusing how to define a python version for a specific project…

I have never researched this, but I thought the .python-version file only exists to benefit other tools which may not have a full TOML parser.

Read-only TOML support is in the standard library since Python 3.11, though. And it's based on an easily obtained third-party package (https://pypi.org/project/tomli/).

(If you want to write TOML, or do other advanced things such as preserving comments and exact structure from the original file, you'll want tomlkit instead. Note that it's much less performant.)

Re: Fun with uv and PEP 723

#63

Post by zahlman »

korijn wrote: 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.

> So in a year or two all of these scripts will be broken because people didn't pin their dependencies?

People act like this happens all the time but in practice I haven't seen evidence that it's a serious problem. The Python ecosystem is not the JavaScript ecosystem.

Re: Fun with uv and PEP 723

#64

Post by heavyset_go »

lxgr wrote: post #6
jkingsman wrote: post #2

uv has been fantastic to use for little side projects. Combining uv run with `uv tool run` AKA `uvx` means one can fetch, install within a VM, and execute Python scripts from Github super easily. No git clone, no venv creation + entry + pip install. And uv is fast — I mean REALLY fast. Fast to the point of suspecting something went wrong and silently errored, when it fact it did just what I wanted but 10x faster than…

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

Last time I looked, pyenv contributors were considering implementing a compiled launcher for that reason.

But that ship has sailed for me and I'm a uv convert.

Re: Fun with uv and PEP 723

#65

Post by heavyset_go »

lxgr wrote: post #13
mikepurvis wrote: post #11

Earlier quoted context omitted.

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.

The Python startup latency thing makes sense, but I really don't understand why it would take `pyenv` a long time to print each line of its "usage" output (the one that appears when invoking it with `--help`) once it's already clearly in the code branch that does only that. It feels like like it's doing heavy work between each line printed! I don't know any other cli tool doing that either.

There's a launcher wrapper shell script + Python startup time that contributes to pyenv's slow launch times.

Re: Fun with uv and PEP 723

#66

Post by int_19h »

wavemode wrote: post #14
Y_Y wrote: post #8

Earlier quoted context omitted.

I think they must have been joking!

Probably not. NPM has its problems but Python packaging has always been significantly messier (partly because, Python is much older than Node and, indeed, much older than the very concept of resolving dependencies over the internet).

The upside in Python is that dependencies tend to be more coarse grained and things break less when you update. With JS you have to be on the treadmill constantly to avoid bitrot, and because packages tend to be so small and dependency trees so large, there's a lot of potential points of failure when updating anything.

Re: Fun with uv and PEP 723

#67

Post by mayli »

js2 wrote: post #47

So far I've only run into one minor ergonomic issue when using `uv run --script` with embedded metadata which is that sometimes I want to test changes to the script via the Python REPL, but that's a bit harder to do since you have to run something like: $ uv run --python=3.13 --with-requirements >> from script import X I'd love if there were something more ergonomic like: $ uv run --with-script script.py python Edit:…

you are welcome

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

Re: Fun with uv and PEP 723

#68

Post by [deleted] »

zahlman wrote: post #62
0cf8612b2e1e wrote: post #23

Earlier quoted context omitted.

I have never researched this, but I thought the .python-version file only exists to benefit other tools which may not have a full TOML parser.

Read-only TOML support is in the standard library since Python 3.11, though. And it's based on an easily obtained third-party package ( https://pypi.org/project/tomli/ ). (If you want to write TOML, or do other advanced things such as preserving comments and exact structure from the original file, you'll want tomlkit instead. Note that it's much less performant.)

[deleted]

Re: Fun with uv and PEP 723

#69

Post by quibono »

Last time I looked at switching from poetry to uv I had an issue with pinning certain dependencies to always install from a private PyPI repository. Is there a way to do that now?

(also: possible there's always been a way and I'm an idiot)

Re: Fun with uv and PEP 723

#70

Post by nomel »

mayli wrote: post #67
js2 wrote: post #47

So far I've only run into one minor ergonomic issue when using `uv run --script` with embedded metadata which is that sometimes I want to test changes to the script via the Python REPL, but that's a bit harder to do since you have to run something like: $ uv run --python=3.13 --with-requirements >> from script import X I'd love if there were something more ergonomic like: $ uv run --with-script script.py python Edit:…

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

This is rather silly.
Post reply on HN