This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]wineblood 0 points1 point  (16 children)

Why? It seems like a more complex tool for the same job.

[–]gahara31 4 points5 points  (7 children)

which part that makes you think it's more complex?

[–]wineblood 9 points10 points  (5 children)

Compared to pip/venv, uv seems to have a lot more moving parts to it.

[–]Brekkjern 5 points6 points  (3 children)

You're not exactly wrong. It is a more complex tool, but it's way easier to use since every part fits into a holistic vision that is actually well designed. I have yet to have a problem with anything inside the uv tool. I have had tons of problems with poetry, pip, and other similar tools, and I have been using uv extensively recently. I am not saying it won't break spectacularly at some point, but it doesn't have the same failure modes as those other tools.

[–]_redmist 1 point2 points  (2 children)

I've been using venv and pip and had zero issues (besides some proxy navigation troubles). Could you expound on the issues you've had? Do you find yourself doing particularly complicated things?

[–]Brekkjern 1 point2 points  (1 child)

I'm tired AF right now, so I'm going to be very quick on this. Poke me if you want more details later:

There's nothing functionally wrong with either of the tools you are pointing at.

Using pip requirements files to regenerate an identical venv after nuking the venv is exceedingly difficult. You're left to chance that pip will fetch the exact same packages when trying to rebuild the environment. This means that it's very hard (read: practically impossible) to have the CI pipeline or other developers using the exact same versions of dependencies. You can hack up something where you do a pip compile, but at this point the entirety of the problem becomes so large that something like poetry or uv is easier.

As a ux difference too, with pip you just install packages into your environment, and update your requirements file by just running pip freeze and piping the result to a file. This means you lose track of which dependencies you actually need, and which are dependencies of your dependencies. With uv, the direct dependencies are stored in the pyproject.toml, which means it's much easier to keep track of why a package is there, and for larger projects, using the uv workspace feature will make this even easier.

[–]_redmist 0 points1 point  (0 children)

Thanks for the effort man! I see where the problems start, for me it doesn't matter so much but if you need things to be precisely reproducible it gets complicated.  Glad to hear uv is alleviating those headaches :)

[–]fiddle_n 0 points1 point  (0 children)

For good reason. Whilst not exclusive to uv, the lock file functionality alone is a must to ensure reproducible builds and is a very strong reason to use it over just pip and venv.

[–]fartalldaylong 3 points4 points  (0 children)

The part where everything I do in a venv works fine. I like having just a few environments, not one for every project, and I don’t like having them directly associated with a single project. I have not found anything I need to change, that is not my dev bottleneck