How is uv awesome and Poetry so bad? They do basically the same things except Astral re-invents the wheel but only part way instead of just relying on the existing tools. uv is fast. As far as I can tell, there's hardly any difference in functionality except for it also replacing PyEnv, which I never use anyway.

uv assuming your local Python is busted to hell and back helps a lot with isolation.

Poetry's CLI would often, for me, just fall over and crash. Crashing a lot is not a fundamental problem in the sense you can fix the bugs, but hey I'm not hitting uv crashes.

pipenv was even worse in terms of just hanging during package resolution. Tools that hang are not tools you want in a CI pipeline!

The end result: `uv run` I expect to work. `pipenv` or `poetry` calls I have to assume don't work, have to put retries into CI pipelines and things like that.

uv has a lot of sensible defaults that prevent clueless developers to shoot their own feet. Uv sync, for example, would uninstall packages not in pyproject.toml

i kind of disagree with this. uv run is clunky, i don't want that. i want to keep the activate the venv and do shit model. i hate uv run as a primitive.

I mean you don't need to use that then. `uv` is still writing to `.venv` by default and you can activate it with `direnv` or w/e.

the point about defaults though, the default or defacto workflow is uv run

Maybe, but that's not how I've been holding it.

I think I have trauma from virtual environments...

Performance aside, uv is more standards compliant than Poetry about the pyproject.toml.

But yes, in terms of user interface they are pretty similar. UV performance really does make the difference.

One of them is written in Rust....

I don't know if it's still true, but ~7 years ago when I last looked at it, Poetry didn't have the kind of UX I have in mind (That Astral/UV do). I remember trying to make it work, and it would choose Python 2 for some reason, despite me never having used it, and it having been obsoleted years before. I remember hitting many problems/errors I can't recall the detail of, but bad UX.

>people continued just using pip -r requirements.txt

What exactly is the issue with this?

The requirements file isn't a lockfile: running that command at different times will give you different venvs.

Right, and that's expected.