Live data from Hacker News

Fun with uv and PEP 723

cottongeeks.com

121–130 of 231 posts

Re: Fun with uv and PEP 723

#121

I've recently updated a Python script that I originally wrote about 10 years ago. I'm not a programmer - I just have to get stuff done - think sysops. For me there used to be a clear delineation between scripting languages and compiled languages. Python has always seemed to want to be both and I'm not too sure it can really. I can live with being mildly wrong about a concept. When Python first came out, our processor…

> Obviously you should install it via a shell script directly from curl!

No? You can install it via pip.

Re: Fun with uv and PEP 723

#122

I've recently updated a Python script that I originally wrote about 10 years ago. I'm not a programmer - I just have to get stuff done - think sysops. For me there used to be a clear delineation between scripting languages and compiled languages. Python has always seemed to want to be both and I'm not too sure it can really. I can live with being mildly wrong about a concept. When Python first came out, our processor…

> Obviously you should install it via a shell script directly from curl! No? You can install it via pip.

You can do both but the official recomendation is shell + curl[0].

Not an expert but I think there's performance gains to calling the binary directly rather than through python.

[0]: https://docs.astral.sh/uv/

Re: Fun with uv and PEP 723

#123

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’ve started doing Python before 2.0 launched. I understand perfectly where you’re coming from.

The answer is an unequivocal yes in this case. uv is on a fast track to be the defacto standard and make pip relegated to the ‘reference implementation’ tier.

Re: Fun with uv and PEP 723

#124
post #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.

It’s amazing for one-offs.

Re: Fun with uv and PEP 723

#125

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…

> finally feels like Python scripts can Just Work™ without a virtualenv scavenger hunt.

Hmm, last time I checked, uv installs into ~/.local/share/uv/python/cpython-3.xx and can not be installed globally e.g. inside a minimal docker without any other python.

So basically it still runs in a venv.

Re: Fun with uv and PEP 723

#126

Earlier quoted context omitted.

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.

Is the environment located in the .venv folder under the same directory as the script?

The venv is created and then discarded once the script finishes execution. This is well suited to one-off scripts like what is demonstrated in the article.

In a larger project you can manage venvs like this using `uv venv`, where you end up with a familiar .venv folder.

Re: Fun with uv and PEP 723

#128
I’ve been a python dev for nearly a decade and never once thought dep management was a problem.

If I’ve ever had to run a “script” in any type of deployed ENV it’s always been done in that ENVs python shell .

So I still don’t see what the fuss is about?

I work on a massive python code base and the only benefit I’ve seen from moving to UV is it has sped up dep installation which has had positive impact on local and CI setup times.

Re: Fun with uv and PEP 723

#129

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…

> Great, if downloading a Linux distro to run sed sounds reasonable.

There's a reason why distroless images exist. :)

Re: Fun with uv and PEP 723

#130
post #120
post #107

Earlier quoted context omitted.

When you solve the dependency management issue for shell scripts, you can also use newer language features because you can ship a newer interpreter the same way you ship whatever external dependencies you have. You don't have to limit yourself to what is POSIX, etc. Depending on how you solve it, you may even be able to switch to a newer shell with a nicer language. (And doing so may solve it for you; since PowerShel…

Nice, if only you could count on having it installed on your fleet, and your fleet is 100pct Linux, no AIX, no HPUX, no SOLARIS, no SUSE on IBM Power.... Been there, tried to, got a huge slap in the face.

Been there, done that. I am so glad I don’t have to deal with all that insanity anymore. In the build farm I was responsible for, I was always happy to work on the Linux and BSD boxes. AIX and HPUX made me want to throw things. At least the Itanium junk acted like a normal server, just a painfully slow one.

I will never voluntarily run a bunch of non-Linux/BSD servers again.

Post reply on HN