←back to thread

Fun with uv and PEP 723

(www.cottongeeks.com)
618 points deepakjois | 7 comments | | HN request time: 2.529s | source | bottom
Show context
4dregress ◴[] No.44374002[source]
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.

replies(7): >>44374205 #>>44374268 #>>44374280 #>>44374598 #>>44375288 #>>44378102 #>>44391546 #
1. petersellers ◴[] No.44374205[source]
> it’s always been done in that ENVs python shell .

What if you don't have an environment set up? I'm admittedly not a python expert by any means but that's always been a pain point for me. uvx makes that so much easier.

replies(2): >>44374524 #>>44378236 #
2. kinow ◴[] No.44374524[source]
I wrote PHP/JS/Java before Python. Been doing Python for nearly a decade too, and like 4dregress haven't had the need to worry much about dep management. JS and PHP had all sorts of issues, Maven & Gradle are still the ones that gave me less trouble. With Python I found that most issues could be fixed by finding the PEP that implemented what I needed, and by trying to come up with a simple workflow & packaging strategy.

Nowadays I normally use `python venv/bin/<some-executable>`, or `conda run -n <some-env> <some-executable>`, or packaged it in a Singularity container. And even though I hear a lot of good things about uv, given that my job uses public money for research, we try to use open source and standards as much as possible. My understanding is that uv is still backed by a company, and at least when I checked it some time ago (in peps discussions & GH issues) they were no implementing the PEPs that I needed -- even if they did, we would probably still stay with simple pip/setuptools to avoid having to use research budget to update our build if the company ever changed its business model (e.g. what anaconda did some months/year? ago).

Digressing: the Singularity container is useful for research & HPC too, as it creates a single archive, which is faster to load on distributed filesystems like the two I work on (GPFS & LustreFS) instead of loading many small files over network.

3. arcanemachiner ◴[] No.44378236[source]
Create a virtual environment:

python3 -m venv venv

Activate the virtual environment:

source venv/bin/activate

Deactivate the virtual environment:

deactivate

replies(1): >>44379071 #
4. petersellers ◴[] No.44379071[source]
Or: `uvx ruff`

Which one is easier to run, especially for someone who doesn't use python everyday?

replies(1): >>44379559 #
5. arcanemachiner ◴[] No.44379559{3}[source]
The one they definitely won't have to re-learn in a few years.
replies(2): >>44380496 #>>44391723 #
6. petersellers ◴[] No.44380496{4}[source]
It's still easier if you use virtual environments so infrequently that you have to look up how to do it every time.
7. fastasucan ◴[] No.44391723{4}[source]
Oh, I am fine re-learning an equivalent of `uvx ruff` every few years, thats not too bad.