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)).
Things uv does better by pip by default: - really hard to install a package globally by accident (pip: forgetting to activate venv) - really easy to distinguish de and main dependencies (pip: create different files for different groups and set up their relationship) - distinguish direct dependencies from indirect dependencies, making it easy to find when a package is not needed anymore (pip: I bet most devs are either not tracking sub dependencies or mixing all together with pip freeze) - easily use different python versions for different projects (pip: not really)
With uv it just works. With pip, technically you can make it work, and I bet you'll screw something up along the way.
> - really hard to install a package globally by accident (pip: forgetting to activate venv)
This is different as of Python 3.11. Please see https://peps.python.org/pep-0668/ for details. Nowadays, to install a package globally, you first have to have a global copy of pip (Debian makes you install that separately), then you have to intentionally bypass a security marker using --break-system-packages.
Also, you don't have to activate the venv to use it. You can specify the path to the venv's pip explicitly; or you can use a different copy of pip (e.g. a globally-installed one) passing it the `--python` argument (you have been able to do this for about 3 years now).
(Pedantically, yes, you could use a venv-installed copy of pip to install into the system environment, passing both --python and --break-system-packages. I can't prove that anyone has ever done this, and I can't fathom a reason beyond bragging rights.)
> - really easy to distinguish [dev] and main dependencies
As of 25.1, pip can install from dependency groups described in pyproject.toml, which is the standard way to group your dependencies in metadata.
> distinguish direct dependencies from indirect dependencies, making it easy to find when a package is not needed anymore
As of 25.1, pip can create PEP 751 standard lockfiles.
> easily use different python versions for different projects
If you want something to install Python for you, yes, that was never in pip's purview, by design.
If you want to use an environment based off an existing Python, that's what venv is for.
For sure, we see the same thing in the JS ecosystem. New tooling adds some feature, other options implement feature, convergence to a larger common set.
I'm still mostly on poetry
The things you list may be a reason for some, but in all discussions I’ve had and read about on uv, the reason is that it behaves as a package manger should. It can just install dependencies from an automatically generated lockfile. It can update outdated minor versions. It can tell me about outdated versions of my dependencies. It can reproduce a build on another machine. The lock file can be put into version control. A coworker can run a single command to install everything. It abstracts the stupidity that is virtual environments away so much you don’t even have to touch them anymore. And also, it’s fast.
Wake me up when pip can do any of that.
> the reason is that it behaves as a package manger should.
This is a matter of opinion. Pip exists to install the packages and their dependencies. It does not, by design, exist to manage a project for you.
The overwhelming majority of developers seem to agree with me though.
If anything, pip is a dependency installer, while working with even trivial projects requires a dependency manager. Parent's point was that pip is actually good enough that you don’t even need uv anymore, but as long as pip doesn’t satisfy 80% of the requirements, that’s just plain false.
I'm not sure an overwhelming majority of Python developers care one way or the other. Like, I'm sure uv is nice, but I've somehow never had an issue with pip or conda, so there's just no reason to futz with uv. Same deal with Jujutsu. It's probably great, but git isn't a problem, so jj isn't a priority.
A majority of HN users might agree with you, but I'd guess that a majority of developers, to paraphrase Don Draper, don't think about it at all.
"anymore" makes no sense, since pip long predates uv.
Some people don't have, or don't care about, the additional requirements you have in mind.
As far as impact on the ecosystem I’d say uv is up there. For the language itself you are right. Curious if you’ve come across any real use cases for Gil-less python. I haven’t yet. Seems like everything that would benefit from it is already written in highly optimized native modules.
I second and third this. I HATE python but uv was what made it usable to me. No other language had such a confusing obnoxious setup to do anything with outside of js land. uv made it sane for me.
Node definitely needs its own "uv" basically.
Why? Uv very good compared to other Python package managers, but even plain npm is still better than uv, and pnpm is a lot better.
How is npm not exactly that?
pnpm
> Seems like everything that would benefit from it is already written in highly optimized native modules
Or by asyncio.
I'm pretty ignorant about this stuff but I think asyncio is for exactly that, asynchronus I/O. Whereas GIL-less Python would be beneficial for CPU bound programs. My day job is boring so I'm never CPU bound, always IO bound on the database or network. If there is CPU heavy code, it's in Numpy. So I'm not sure if Gil-less actually helps there.
asyncio is unrelated to the parallelism prevented by the GIL.
Type annotations were introduced in 2008 and even type hints over decade ago in Sept 2015.
But there has been continual improvement over that time, both in the ecosystem, and in the language (like a syntax for generics).
And yet you still cannot write even moderately complex type expressions without severe pain.
typed annotations that are useful.
Currently they are a bit pointless. Sure they aid in documentation, but they are effort and cause you pain when making modifications (mind you with halfarse agentic coding its probably less of a problem. )
What would be better is to have a strict mode where instead of duck typing its pre-declared. It would also make a bunch of things faster (along with breaking everything and the spirit of the language)
I still don't get the appeal of UV, but thats possibly because I'm old and have been using pyenv and venv for many many years. This means that anything new is an attack on my very being.
however if it means that conda fucks off and dies, then I'm willing to move to UV.
You can get pretty darn close to static typing by using ty (from the same team as uv).
I've been using it professionally and its been a big improvement for code quality.
> it's just another package manager among many
It's the python version of fink vs macports vs homebrew. Or apt vs deb. or pkgsrc vs ports.
But I don't think "its just another" gets the value proposition here. It's significantly simpler to deploy in practice for people like me, writing ad hoc scripts and running git downloaded scripts and codelets.
Yes, virtualenv and pip existed. No, they turned out to be a lot more fiddly to run in practice than UV.
That UV is rust is funny, but not in a terrible way. The llvm compiler toolchain is written in C but compiles other languages. Using one language to do things for another language isn't such a terrible outcome.
I hope UV supplants the others. Not to disrespect their authors, but UV is better for end users. If its worse for package maintainers I think the UV authors should be told.
I don't want type annotations. Was kinda the point of Python not to deal with types.
If you've ever used python on a project above a certain size (both lines of code and people who contribute to it), type annotations quickly become something you find useful.
I have, it didn't really help. It does help if you have no tests, but a large project needs tests.
I guess you don't use an IDE. Use VSCode or IntelliJ with auto completion and error highlighting as you type. Type hints are a blessing.
PyCharm does this without the hints
How would that work across files and libraries?
One problem is when people store different types in the same variable, what type is it at the time I use it.
Types save you cognitive effort and catch errors earlier, while writing code, not later when running or testing
They shouldn't do that. I get how adding more checks obviously helps in a way, but only if you ignore the cost. It's not worth the effort that you could instead spend writing better tests. Most of the time your type is like FooFactory which doesn't tell you much anyway.
Then again it's not so bad if you're willing to make AI add all the types and not even care.
What happend with GIL-removal
You can disable it, here's the PEP, search has more digestible options
https://peps.python.org/pep-0703/