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

11–20 of 231 posts

Re: Fun with uv and PEP 723

#11

Post by mikepurvis »

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.

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.

Re: Fun with uv and PEP 723

#12

Post by ACAVJW4H »

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 time, space, and the Nix manual. Docker? Great, if downloading a Linux distro to run sed sounds reasonable.

There’s got to be a middle ground simple, declarative, and built for humans.

Re: Fun with uv and PEP 723

#13

Post by lxgr »

mikepurvis wrote: post #11
lxgr wrote: 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.

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.

Re: Fun with uv and PEP 723

#14

Post by wavemode »

Y_Y wrote: post #8
k__ wrote: post #4

Pretty nice! Some Python devs told me, it's an awesome language, but they envy the Node.js ecosystem for their package management. Seems like uv finally removed that roadblock.

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

Re: Fun with uv and PEP 723

#15

Post by fouronnes3 »

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…

Consider porting your shell scripts to Python? The language is vastly superior and subprocess.check_call is not so bad.

Re: Fun with uv and PEP 723

#16

Post by SmellTheGlove »

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…

Would homebrew do the job?

Re: Fun with uv and PEP 723

#17

Post by ndr »

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…

Why bother writing new shell scripts?

If you're allowed to install any deps go with uv, it'll do the rest.

I'm also kinda in love with https://babashka.org/ check it out if you like Clojure.

Re: Fun with uv and PEP 723

#19

Post by doctoboggan »

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?

Re: Fun with uv and PEP 723

#20

Post by sambaumann »

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 (it's defined in both .python-version and pyproject.toml)

Post reply on HN