Live data from Hacker News

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

emily.space

141–150 of 1001 posts

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

#141

Does speed really matter during python installation?

Speed matters everywhere. How much compute is spent on things that could easily be 100x faster than they are? Compare using VMware with pip to run a battery of unit tests with firecracker plus uv. It’s orders of magnitude quicker, and avoids a whole suite of issues related to persistent state on the machine

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

#142

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

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.

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

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

Yeah, I'm with you. I'm forcing myself to learn it because it looks like that's the way PyWorld is going. I don't dislike uv as much as poetry. But I guess I never really ran into issues using pyenv and pip. shrug Maybe I wasn't working on complex enough projects.

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

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

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

No you don't. That's just a set of compatibility approaches for people who can't let go of pip/venv. Move to uv/PEP723, world's your oyster.

> It does not play well with Docker.

Huh? I use uv both during container build and container runtime, and it works just fine?

> You end up needing to understand all of these new environmental variables

Not encountered the need for any of these yet. Your comments on uv are so far out of line of all the uses I've seen, I'd love to hear what you're specifically doing that these become breaking points.

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

#147

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.

As long as your `/usr/bin/env` supports `-S`, yes.

It will install and use distribution packages, to use PyPA's terminology; the term "module" generally refers to a component of an import package. Which is to say: the names you write here must be the names that you would use in a `uv pip install` command, not the names you `import` in the code, although they may align.

This is an ecosystem standard (https://peps.python.org/pep-0723/) and pipx (https://pipx.pypa.io) also supports it.

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

#148

I haven't tried uv yet, but I did use it's precursor - rye. I had to update some messy python code and I was looking for a tool that could handle python versions, package updates, etc. with the least amount of documentation needing be read and troubleshooting. Rye was that for me! Next time I write python I'm definitely going to use uv.

Indeed rye is great and switching to uv is pretty straight forward. I still think rye's use of shims was pretty cool but probably uv's approach is more sane

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

#149
I gotta say, I feel pretty vindicated after hearing for years how Python’s tooling was just fine and you should just use virtualenv with pip and how JS must be worse, that when Python devs finally get a taste of npm/cargo/bundler in their ecosystem, they freaking love it. Because yes, npm has its issues but lock files and consistent installs are amazing

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

#150
post #46

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.

> uv will magically install and use the specified modules. As long as you have internet access, and whatever repository it's drawing from is online, and you may get different version of python each time, ...

I mean, if you use == constraints instead of >= you can avoid getting different versions, and if you’ve used it (or other things which combined have a superset of the requirements) you might have everything locally in your uv cache, too.

But, yes, python scripts with in-script dependencies plus uv to run them doesn't change dependency distribution, just streamlines use compared to manual setup of a venv per script.

Post reply on HN