Live data from Hacker News

Fun with uv and PEP 723

cottongeeks.com

21–30 of 231 posts

Re: Fun with uv and PEP 723

#21

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…

> Packaging, dependency management, and reproducibility in shell land are still stuck in the Stone Ages.

IMO it should stay that way, because any script that needs those things is way past the point where shell is a reasonable choice. Shell scripts should be small, 20 lines or so. The language just plain sucks too much to make it worth using for anything bigger.

Re: Fun with uv and PEP 723

#22

If PEP 723 is only an enhancement proposal does it work only because `uv` happens to support it? Can you not use `uvx` with your script because it only works on packages that are installed already or on PyPi?

uvx is useful to run scripts inside PyPi packages. It does not support running Python scripts directly

You can use uvx run scripts with a combination of the --with flag to specify the dependencies and invoking python directly. For e.g

uvx --with youtube-transcript-api python transcript.py

But you wont get the benefit of PEP 723 metadata.

Re: Fun with uv and PEP 723

#23

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.

Re: Fun with uv and PEP 723

#24

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?

I'm not a Python master but I've struggled with all the previous package managers, and uv is the first tool that does everything easily (whether it's installing or generating packages or formatting or checking your code).

I don't know why there is such a flurry of posts since it's a tool that is more than a year old, but it's the one and only CLI tool that I recommend when Python is needed for local builds or on a CI.

Hatch was a good contender at the time but they didn't move fast enough, and the uv/ruff team ate everybody's lunch. uv is really good and IMHO it's here to stay.

Anyway try it for yourself but it's not a high-level tool that is hiding everything, it's fast and powerful and yet you stay in control. It feels like a first-party tool that could be included in the Python installer.

Re: Fun with uv and PEP 723

#25

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…

> there should be a defined path to switch from a requirements.txt based workflow to uv

Try `uvx migrate-to-uv` (see https://pypi.org/project/migrate-to-uv/)

Re: Fun with uv and PEP 723

#26

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…

For the specific case of solving shell script dependencies, Nix is actually very straightforward. Packaging a script is a writeShellApplication call and calling it is a `nix run`.

I guess the issue is just that nobody has documented how to do that one specific thing so you can only learn this technique by trying to learn Nix as a whole.

So perhaps the thing you're envisaging could just be a wrapper for this Nix logic.

Re: Fun with uv and PEP 723

#27

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?

The learning curve is so low that yes.

Try it for <20mins and if you don't like it, leave it behind. These 20mins include installation, setup, everything.

Re: Fun with uv and PEP 723

#28
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 "slowness" and the utter insanity of trying to make a "works on my computer" Python program work on another computer pushed me to just rewrite all my Python stuff in Go.

About 95% of my Python utilities are now Go binaries cross-compiled to whatever env they're running in. The few remaining ones use (API) libraries that aren't available for Go or aren't mature enough for me to trust them yet.

Re: Fun with uv and PEP 723

#29

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?

I also went through a similar enlightenment of just sticking to pip, but uv convinced me to switch and I’m so glad I did. You can dip your toe in by just using the ‘uv pip’ submodule as a drop in replacement for pip but way faster.

Re: Fun with uv and PEP 723

#30

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 write an ebook on Python Developer tooling. I've attempted to address some of the weaknesses in the official documentation.

How to migrate from requirements.txt: https://pydevtools.com/handbook/how-to/migrate-requirements.... How to change the Python version of a uv project: https://pydevtools.com/handbook/how-to/how-to-change-the-pyt...

Let me know if there are other topics I can hit that would be helpful!

Post reply on HN