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

161–170 of 231 posts

Re: Fun with uv and PEP 723

#161

Post by mmcnl »

rednafi wrote: post #144
4dregress wrote: post #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…

I guess this is why people need to get out of this “Python dev” or “JS dev” mindset and try other languages to see why those coming to Python complain so much about dependency management. People complain because the experience is less confusing in many other languages. Think Go, Rust, or even JS. All the tooling chaos and virtual environment jujitsu are real deterrents for newcomers. And it’s not just beginners compl…

Confusing is underselling it. That implies that Python dependency management is working fine, it's just complex. But it's not working fine: there's no such thing as lock files, which makes reproducible installs a gamble and not a given. For small scripts this is probably "okay", but if you're working in a team or want to deploy something on a server, then it's absolutely not fine because you want deterministic builds and that's simply impossible without a decent package manager.

Tools like uv solve the "it works on my machine" problem. And it's also incredibly fast.

Re: Fun with uv and PEP 723

#162

Post by mmcnl »

4dregress wrote: post #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…

Virtual environments alone are not enough. They don't guarantee deterministic builds. What do you do to ensure that your production environment runs the same code as your local dev environment? How do you solve that problem without dependency managers like uv or poetry?

Re: Fun with uv and PEP 723

#163

Post by syhol »

Mise has a very similar feature with its shebangs: https://mise.jdx.dev/tips-and-tricks.html#shebang

    #!/usr/bin/env -S mise x xh jq fzf gum -- bash
    todo=$(xh 'https://jsonplaceholder.typicode.com/todos' | jq '.[].title' | fzf)
    gum style --border double --padding 1 "$todo"
It makes throwing together a bash scripts with dependencies very enjoyable

Re: Fun with uv and PEP 723

#164

Post by mmcnl »

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 agree the docs are not there yet. There is a lot of documentation but it's a description of all the possible options that are available (which is a lot). But it doesn't really tell me how to actually _use_ it for a certain type of workflow, or does a mediocre job at best.

Re: Fun with uv and PEP 723

#165

Post by mmcnl »

indosauros wrote: post #54
tpoacher wrote: post #51

What's going on? This whole thread reads like paid amazon reviews

What's going on is "we have 14 standards so we need to create a 15th" actually worked this time

To be fair, I've used Poetry for years and it works/worked amazingly well. It's just not as fast as uv.

Re: Fun with uv and PEP 723

#166

Post by rednafi »

mmcnl wrote: post #161
rednafi wrote: post #144

Earlier quoted context omitted.

I guess this is why people need to get out of this “Python dev” or “JS dev” mindset and try other languages to see why those coming to Python complain so much about dependency management. People complain because the experience is less confusing in many other languages. Think Go, Rust, or even JS. All the tooling chaos and virtual environment jujitsu are real deterrents for newcomers. And it’s not just beginners compl…

Confusing is underselling it. That implies that Python dependency management is working fine, it's just complex. But it's not working fine: there's no such thing as lock files, which makes reproducible installs a gamble and not a given. For small scripts this is probably "okay", but if you're working in a team or want to deploy something on a server, then it's absolutely not fine because you want deterministic builds…

There is a lock file now.

https://packaging.python.org/en/latest/specifications/pylock...

Issue is since there are no standardized build tool (pip, uv both are third party), there are a zillion ways of generating this lockfile unlike go.mod or cargo.toml. So it doesn't work in many scenarios and it's confusing as hell.

Re: Fun with uv and PEP 723

#167

Post by oblio »

zahlman wrote: post #94
oblio wrote: post #75

Earlier quoted context omitted.

The bigger problem in Python has been its slowness and reliance on C dependencies. Maven solved Java packaging circa 2005, for example. Yes, XML is verbose, but it's an implementation detail. Python still lags on many fronts, 20 years later. An example: even now it makes 0 sense to me why virtual envs are not designed and supposed to be portable between machines with the same architecture (!). Or why venvs need to be…

> An example: None of this example has anything to do with performance or reliance on C dependencies, but ok. > even now it makes 0 sense to me why virtual envs are not designed and supposed to be portable between machines with the same architecture (!). They aren't designed to be relocatable at all - and that's the only actual stumbling block to it. (They may even contain activation scripts for other platforms!) Tha…

> None of this example has anything to do with performance or reliance on C dependencies, but ok.

You'd realize why I wrote that if you used Java/Maven. Java is by and large self-contained. Stuff like Python, Ruby, PHP, Javascript[1] etc, are not, they depend on system libraries.

So when you install something on Solaris, FreeBSD, MacOS, Windows, well, then you have to deal with the whole mess.

1. Is the C dependency installed on the system? 2. Is it the correct major version or minor version? 3. Has it been compiled with the correct flags or whatnot? 4. If it's not on the system, can the programming language specific package manager pull a binary from a repo for my OS-arch combo? 5. If there's no binary, can the programming language specific package manager pull the sources and compile them for my OS-arch combo?

All of those steps can and do fail, take time, and sometimes you have to handle them yourself because of bugs.

Java is fast enough that almost everything can be written in Java, so 99% of the libraries you use only have 1 artifact: the universal jar, and that's available in Maven repos. No faffing around with wheels or whatnot, or worse, with actual system dependencies that are implicitly (or explicitly) required by dependencies written in the higher level programming language.

I won't even bother to address in detail the insanity that you described about virtual envs, it's just Stockholm syndrome. Almost every other programming language does just fine without venvs. Also I don't really buy that issue with the lack of portability, it's just a bunch of bad design decision early on in Python's design. Even for Windows there are better possibilities (symlinks are feasible, you just need admin access).

I say this as someone who's used basically all mainstream programming language over the years.

The sane way to do virtual envs is to have them be just... folders. No absolute paths, no activation, just have a folder and a configuration file. The launcher automatically detects a configuration file with the default name and the configuration file in turn points the launcher and Python to use the stuff in the folder.

Deployment then becomes... drumroll just copying the folder to another machine (usually zipping/unzipping it first).

* * *

[1] Javascript is a bit of a special case but it's still slower than Java, on average.

Re: Fun with uv and PEP 723

#168

Post by zelphirkalt »

Using Guix (guix shell) it was already possible to run Python scripts one-off. I see others have also commented about doing it using Nix.

Also that would be reproducible, in contrast to what is shown in the blog post. To make that reproducible, one would have to keep the lock file somewhere, or state the checksums directly in the Python script file, which seems rather un-fun.

Re: Fun with uv and PEP 723

#169

Post by 4dregress »

rednafi wrote: post #144
4dregress wrote: post #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…

I guess this is why people need to get out of this “Python dev” or “JS dev” mindset and try other languages to see why those coming to Python complain so much about dependency management. People complain because the experience is less confusing in many other languages. Think Go, Rust, or even JS. All the tooling chaos and virtual environment jujitsu are real deterrents for newcomers. And it’s not just beginners compl…

My view is I’m an engineer first and foremost and I use the tools which are best for the task at hand. That also means what’s best for the business in terms of others working on the project, this has meant python with some sort of framework.

People have suggested using other languages that might be faster but the business always choices what’s best for everyone to work with.

Re: Fun with uv and PEP 723

#170

Post by est »

ndr wrote: post #157
est wrote: post #125

Earlier quoted context omitted.

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

https://docs.astral.sh/uv/reference/settings/#pip_system

I mean how to install `uv python install` into system-wide.

No matter what I tried it's always a symlink into ~/.local

Post reply on HN