Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

emily.space

Post reply on HN
Print view View original

111–120 of 1001 posts

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

#111

Post by dragonwriter »

kyt wrote: 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…

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

uv doesn’t try to replace ruff.

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

"uv pip" doesn't use pip, it provides a low-level pip-compatible interface for uv, so it is, in fact, still uv replacing pip, with the speed and other advantages of uv when using that interface.

Also, while I’ve used uv pip and uv venv as part of familiarizing myself with the tool, I’ve never run into a situation where I need either of those low-level interfaces rather than the normal high-level interface.

> It does not play well with Docker.

How so?

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

#114

Post by zahlman »

verdverm wrote: post #11

I'd put type annotations and GIL removal above UV without a second thought. UV is still young and I hit some of those growing pains. While it is very nice, I'm not going to put it up there with sliced bread, it's just another package manager among many

For that matter, IMX much of what people praise uv for is simply stuff that pip (and venv) can now do that it couldn't back when they gave up on pip. Which in turn has become possible because of several ecosystem standards (defined across many PEPs) and increasing awareness and adoption of those standards.

The "install things that have complex non-Python dependencies using pip" story is much better than several years ago, because of things like pip gaining a new resolver in 2020, but in large part simply because it's now much more likely that the package you want offers a pre-built wheel (and that its dependencies also do). A decade ago, it was common enough that you'd be stuck with source packages even for pure-Python projects, which forced pip to build a wheel locally first (https://pradyunsg.me/blog/2022/12/31/wheels-are-faster-pure-...).

Another important change is that for wheels on PyPI the installer can now obtain separate .metadata files, so it can learn what the transitive dependencies are for a given version of a given project from a small plain-text file rather than having to speculatively download the entire wheel and unpack the METADATA file from it. (This is also possible for source distributions that include PKG-INFO, but they aren't forced to do so, and a source distribution's metadata is allowed to have "dynamic" dependencies that aren't known until the wheel is built (worst case) or a special metadata-only build hook is run (requires additional effort for the build system to support and the developer to implement)).

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

#115

Post by j45 »

aerhardt wrote: post #26

I'm surprised by how much I prefer prepending "uv" to everything instead of activating environments - which is still naturally an option if that's what floats your boat. I also like how you can manage Python versions very easily with it. Everything feels very "batteries-included" and yet local to the project. I still haven't used it long enough to tell whether it avoids the inevitable bi-yearly "debug a Python enviro…

This isn't a comment just about Python.. but it should just work. There shouldn't be constant ceremony for getting and keeping environments running.

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

#116

Post by maccard »

d4mi3n wrote: post #42
LeoPanthera wrote: post #18

For single-file Python scripts, which 99% of mine seem to be, you can simplify your life immensely by just putting this at the top of the script: #!/usr/bin/env -S uv run --script # /// script # requires-python = ">=3.11" # dependencies = [ "modules", "here" ] # /// The script now works like a standalone executable, and uv will magically install and use the specified modules.

If I were to put on my security hat, things like this give me shivers. It's one thing if you control the script and specified the dependencies. For any other use-case, you're trusting the script author to not install python dependencies that could be hiding all manner of defects or malicious intent. This isn't a knock against UV, but more a criticism of dynamic dependency resolution. I'd feel much better about this i…

If that’s your concern you should be auditing the script and the dependencies anyway, whether they’re in a lock file or in the script. It’s just as easy to put malicious stuff in a requirements.txt

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

#117

Post by j45 »

kyt wrote: 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…

It's still one tool to orchestrate and run everything, which is preferable to many.

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

#118

Post by eatonphil »

notatallshaw wrote: post #94
eatonphil wrote: post #74

Earlier quoted context omitted.

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

> I had been hoping someone would introduce the non-virtualenv package management solution that every single other language has where there's a dependency list and version requirements (including of the language itself) in a manifest file (go.mod, package.json, etc) and everything happens in the context of that directory alone without shell shenanigans. Isn't that exactly a pyproject.toml via the the uv add/sync/run…

> pyproject.toml

Ah ok I was missing this and this does sound like what I was expecting. Thank you!

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

#119

Post by Carbonhell »

curiousgal wrote: post #10

The best thing to happen to the Python ecosystem would be something that unites pip and conda. Conda is not going anywhere given how many packages depend on non-python binaries, especially in enterprise settings.

You might be interested in Pixi: https://prefix.dev/ It uses uv under the hood for Python dependencies, while allowing you to also manage Conda dependencies in the same manifest (pixi.toml). The ergonomics are really nice and intuitive imo, and we're on our way to replace our Poetry and Conda usage with only Pixi for Python/C++ astrodynamics projects. The workspace-centric approach along with native lockfiles made most of our package management issues go away. I highly recommend it! (Not affiliated anyhow, other than contributing with a simple PR for fun)

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

#120

Post by collinmanderson »

nothrowaways wrote: post #103

Does speed really matter during python installation?

It's fast enough that sometimes dependencies can be checked and resolved and installed at program runtime rather than it needing to be a separate step.

You can go from no virtual environment, and just "uv run myfile.py" and it does everything that's needed, nearly instantly.

Post reply on HN