Live data from Hacker News

Uv is the best thing to happen to the Python ecosystem in a decade

emily.space

101–110 of 1001 posts

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#101
post #21

I must be the odd man out but I am not a fan of uv. 1. It tries to do too many things. Please just do one thing and do it well. It's simultaneously trying to replace pip, pyenv, virtualenv, and ruff in one command. 2. You end up needing to use `uv pip` so it's not even a full replacement for pip. 3. It does not play well with Docker. 4. It adds more complexity. You end up needing to understand all of these new enviro…

> 2. You end up needing to use `uv pip` so it's not even a full replacement for pip. Needing pip and virtualenvs was enough to make me realize uv wasn't what I was looking for. If I still need to manage virtualenvs and call pip I'm just going to do so with both of these directly. I had been hoping someone would introduce the non-virtualenv package management solution that every single other language has where there's…

In most cases, you don't really need to manage virtual envs though ? uv commands that need a venv will just create one for you or install to the existing one automatically.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#102
post #21

I must be the odd man out but I am not a fan of uv. 1. It tries to do too many things. Please just do one thing and do it well. It's simultaneously trying to replace pip, pyenv, virtualenv, and ruff in one command. 2. You end up needing to use `uv pip` so it's not even a full replacement for pip. 3. It does not play well with Docker. 4. It adds more complexity. You end up needing to understand all of these new enviro…

> 1. It tries to do too many things. Please just do one thing and do it well. It's simultaneously trying to replace pip, pyenv, virtualenv, and ruff in one command.

I think there are more cases where pip, pyenv, and virtualenv are used together than not. It makes sense to bundle the features of the three into one. uv does not replace ruff.

> 2. You end up needing to use `uv pip` so it's not even a full replacement for pip.

uv pip is there for compatibility and to facilitate migration but once you are full on the uv workflow you rarely need `uv pip` if ever

> 3. It does not play well with Docker.

In what sense?

> 4. It adds more complexity. You end up needing to understand all of these new environmental variables: `UV_TOOL_BIN_DIR`, `UV_SYSTEM_PYTHON`, `UV_LINK_MODE`, etc.

You don't need to touch them at all

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#104
post #31

Earlier quoted context omitted.

can't you just do curl|more and then view what it's going to do? Then, once you're convinced, go back to curl|sh. /just guessing, haven't tried it

A malicious server could detect whether the user is actually running "curl | sh" instead of just "curl" and only serve a malicious shell script when the code is executed blindly. See this thread for reference: https://news.ycombinator.com/item?id=17636032

well you still have to execute the shell script at some point. You could do curl > install.sh, open it up to inspect, and then run the install script which would still trigger the callback to the server mentioned in the link you posted. I guess it's really up to the user to decide what programs to run and not run.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#105

curl|sh and iwr|iex chills my spine, no one should recommend these methods of installation in 2025. I'm against closed computers but I'm also against reckless install. Even without the security concerns these way of installation tends to put files in a whole random places making it hard to manage and cleanup.

That iwr|iex example is especially egregious because it hardcodes the PowerShell already an execution bypass, so including a second one seems a red flag to me. (What else is it downloading?)

Also, most reasonable developers should already be running with the ExecutionPolicy RemoteSigned, it would be nice if code signing these install script was a little more common, too. (There was even a proposal for icm [Invoke-Command] to take signed script URLs directly for a much safer alternative code-golfed version of iwr|iex. Maybe that proposal should be picked back up.)

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#106
post #72
post #21

I must be the odd man out but I am not a fan of uv. 1. It tries to do too many things. Please just do one thing and do it well. It's simultaneously trying to replace pip, pyenv, virtualenv, and ruff in one command. 2. You end up needing to use `uv pip` so it's not even a full replacement for pip. 3. It does not play well with Docker. 4. It adds more complexity. You end up needing to understand all of these new enviro…

Your implication is that pyenv, virtualenv, and pip should be 3 different tools. But for the average developer, these tools are all related to managing the python environment and versions which in my head sounds like one thing. Other languages don't have 3 different tools for this. pip and virtualenv also add a ton of complexity and when they break (which happens quite often) debugging it is even harder despite them…

Python versions and environments can be solved in more reliable abstraction level as well, e.g. if you are heavy Nix user.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#107

Venv seems pretty straightforward once you’ve learned the one activate command. I don’t really get that uv solves all these problems ve never encountered. Just make a venv and use it seems to work fine.

If that works for you, then that's cool. Personally, I don't want to think about environments, and it's weird that python is the only language that has venvs. Having a tool that handles it completely transparently to me is ideal, to me.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#109
post #70

Can't agree more. We were using pyenv+poetry before and regularly had to pin our poetry version to a specific one, because new poetry releases would stall trying to resolve dependencies. pyenv was problematic because you needed the right concoction of system packages to ensure it compiled python with the right features, and we have a mix of MacOS and Linux devs so this was often non-trivial. uv is much faster than bo…

> because new poetry releases would stall trying to resolve dependencies. > uv is much faster than both of these tools conda is also (in)famous for being slow at this, although the new mamba solver is much faster. What does uv do in order to resolve dependencies much faster?

> What does uv do in order to resolve dependencies much faster?

- Representing version numbers as single integer for fast comparison.

- Being implemented in rust rather than Python (compared to Poetry)

- Parallel downloads

- Caching individual files rather than zipped wheel, so installation is just hard-linking files, zero copy (on unix at least). Also makes it very storage efficient.

Post reply on HN