Astral Blog

The reason there have been so many is because the standard included tools (pip, venv) are not great. And others could still use improvements.

Venv and setup tools aren't really package managers. Pipx is only meant for installing Dev tools per user (in isolated Venvs).

pyenv does something a bit different from those tools you listed(maybe it'd part of cones I haven't tried it). Its not a dependency manager its a python version manager like nvm (node version manager). It helps you manage downloading and compiling python from source and it let's you specify python version in a .python-version file and provides a shim to find the right python for a project(compiling it if its not already available).

I tried pipenv and despite being hyped for it, it had a lot of issues. Then I tried poetry which seemed much better but was still sort of slow and got stuck updating lock files sometimes.

I haven't even tried pdm. Or various conda package managers since its mainly used by scientists with lots of binary dependency needs.

Then ~~uv~~ rye came along and seemed to fix things. It replaced pip+pip tools/pipenv/poetry. Also replaced pipx(install python tools in isolated venvs then add it to users ./local/bin). Also replaced pyenv but instead of compiling python which takes a while and can be troublesome it downloads portable builds https://astral.sh/blog/python-build-standalone (which do have some downsides/compatibility issues but are usually better then compiling python). It was…

This is awesome!

Is there uv support?[0]

One of my biggest gripes about brew is how they manage dependencies. The devs have a conflicting philosophy that creates bloat. Package maintainers must define settings, settings should always use the latest Python version. It makes no sense. Maintainers won't update unless things break so you got a bunch of Python versions running around. And it won't use system Python!

Uv seems to provide an elegant solution for this. You can build a venv for each package and rust version will only have the specified deps. Since uv finds all your Python instances (and packages) and soft links them you have way less bloat and venvs become really useful. You can also use run and other tools to handle executables

Plus is also rust so good synergy ;)

[0] https://astral.sh/blog/uv

Here's something I ran into recently. An `env` script started showing up in my path messing with my plain UNIX `env` command usage. Turns out uv's installer creates this when you run

curl -LsSf https://astral.sh/uv/install.sh | sh

1202│ # In this case we need to:¬
1203│ #¬
1204│ # * Install to $HOME/.cargo/bin/¬
1205│ # * Create a shell script at $HOME/.cargo/env that:¬
1206│ # * Checks if $HOME/.cargo/bin/ is on PATH¬
1207│ # * and if not prepends it to PATH¬
1208│ # * Ed

What kind of programmers are writing this stuff overriding my default unix commands with this?

uv uses very agressive caching (https://docs.astral.sh/uv/concepts/cache/) but pytorch has many, many different combinations of packages for the same release.

It's not uncommon to have to download pytorch many times, because some lib may specify one slightly different version than another: https://docs.astral.sh/uv/guides/integration/pytorch/#configuring-accelerators-with-environment-markers

pytorch causes many headaches in the ecosystem, and a better handling of it is one thing their commercial offering, pyx, wants to fix: https://astral.sh/blog/introducing-pyx

I'm not sure if you're aware, but there's the Wheel Variants proposal [0] that the WheelNext initiative is working through that was presented at PyCon 2025 [1][2], which hopes to solve some of those problems.

uv has implemented experimental support, which they announced here [3].

[0] https://wheelnext.dev/proposals/pepxxx_wheel_variant_support/

[1] https://us.pycon.org/2025/schedule/presentation/100/

[2] https://www.youtube.com/watch?v=1Oki8vAWb1Q

[3] https://astral.sh/blog/wheel-variants