Live data from Hacker News

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

emily.space

281–290 of 1001 posts

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

#281
post #239

Earlier quoted context omitted.

I have used pip freeze > requirements.txt pip install -r requirements.txt Way before "official" lockfile existed. Your requirements.txt becomes a lockfile, as long as you accept to not use ranges. Having this in a single tool etc why not, but I don't understand this hype, when it was basically already there.

That works for simple cases. Now, update a transitive dependency used by more than one dependency. You might get lucky and it'll just work.

Not sure how uv helps here, because I am not very familiar with it.

With pip you update a dependency, it won't work if it's not compatible, it'll work if they are. Not sure where the issue is?

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

#282
And still there are some annoying issues:

  dependencies = [
      "torch==2.8.0+rocm6.4",
      "torchvision==0.23.0+rocm6.4",
      "pytorch-triton-rocm==3.4.0",
  ...
  ]
There is literally no easy way to also have a configuration for CUDA, you have to have a second config, and, the worse, manually copy/symlink them into the hardcoded pyproject.toml file

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

#283
post #169

A problem remain in that many and still more of the popular repositories don't use uv to manage their dependencies. So you are back having to use conda and the rest. Now, you have yet another package manager to handle. I wouldn't be harsh to engineers at astral who developed amazing tooling, but the issue with the python ecosystem isn't lack of tooling, it is the proliferation and fragmentation. To solve dependency m…

Don't they publish to PyPi? What do you care what they use behind the scenes?

It isn't what they use under the scene.

I refered to the interfaces of other packaging tools. I use uv and it's excellent on its own.

You get a repo, it's using playwright, what do you do now ? You install all the dependencies found in the dependency descriptor then sync to create a uv descriptor. or you compose a descriptor that uv understands.

It's repetitive, rather systematic so it could be automated. I should volunteer for a PR but my point is introducing yet another tool to an ecosystem suffering a proliferation of build and deps management tooling expands the issue. It would have been helpful from the get go to support existing and prolific formats.

pnpm understands package.json It didn't reinvent the wheel be cause we have millions of wheels out there. It created its own pnpm lock file, but that's files a user isn't meant to touch so it goes seamlessly to transition from npm to pnpm. Almost the same when migrating from webpack to rsbuild.

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

#284
post #167
post #160

I love uv. But the post starts with a simple install using a oneliner curl piping to sh, which is such a big attack surface area… I would much rather have a much longer one liner that increases safety.

Isn't uv like... a Rust binary? If that sh has any sense it just copies the binary and adds it to PATH.

but since you are curling a web URL straight to sh you will never know. which is the problem.

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

#285

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

There is nothing I dread more within the general context of software development, broadly , than trying to run other people's Python projects. Nothing. It's shocking that it has been so bad for so long.

I was into Python enough that I put it into my username but this is also my experience. I have had quasi-nightmares about just the bog of installing a Python project.

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

#286

Seeing a `pip install -r requirements.txt` in a very recently created python project is almost a red flag now...

requirements.txt allows pip arguments to be included, so can be doing much more than just listing package names.

For example, installing on an air gapped system, where uv barely has support.

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

#287
Python is not my first language but I've always liked it. But project and dependency management was always a bit meh and an afterthought.

Over the years, I've tried venv, conda, pipenv, petry, plain pip with requirements.txt. I've played with uv on some recent projects and it's a definite step up. I like it.

Uv actually fixes most of the issues with what came before and actually builds on existing things. Which is not a small compliment because the state of the art before uv was pretty bad. Venv, pip, etc. are fine. They are just not enough by themselves. Uv embraces both. Without that, all we had was just a lot of puzzle pieces that barely worked together and didn't really fit together that well. I tried making conda + pipenv work at some point. Pipenv shell just makes using your shell state-full just adds a lot of complexity. None of the IDEs I tried figured that out properly. I had high hopes for poetry but it ended up a bit underwhelming and still left a lot of stuff to solve. Uv succeeds in providing a bit more of an end to end solution. Everything from having project specific python installation, venv by default without hassle, dependency management, etc.

My basic needs are simple. I don't want to pollute my system python with random crap I need for some project. So, like uv, I need to have whatever solution deal with installing the right python version. Besides, the system python is usually out of date and behind the current stable version of python which is what I would use for new projects.

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

#288

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

There is nothing I dread more within the general context of software development, broadly , than trying to run other people's Python projects. Nothing. It's shocking that it has been so bad for so long.

I agree with you wholeheartedly, besides not preferring dynamic programming languages, I would in the past have given python more of a look because of its low barrier to entry...but I have been repulsed by how horrific the development ux story has been and how incredibly painful it is to then distribute the code in a portable ish way.

UV is making me give python a chance for the first time since 2015s renpy project I did for fun.

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

#289
post #2

Idk, for me ruff was more of a game changer. No more explaining why we need both flake8 and pylint (and isort), no more flake8 plugins... Just one command that does it all. UV is great but I use it as a more convenient pip+venv. Maybe I'm not using it to it's full potential.

I agree flake8 -> ruff was more of a game changer for me than pip+venv -> uv. I use flake8/ruff for more often than pip/venv.

uv is probably much more of a game changer for beginner python users who just need to install stuff and don't need to lint. So it's a bigger deal for the broader python ecosystem.

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

#290
post #239

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

I have used pip freeze > requirements.txt pip install -r requirements.txt Way before "official" lockfile existed. Your requirements.txt becomes a lockfile, as long as you accept to not use ranges. Having this in a single tool etc why not, but I don't understand this hype, when it was basically already there.

It is also manages the runtime, so you can pin a specific runtime to a project. It is very useful and worth investigating.
Post reply on HN