Hacker News Reader

Comment by Kwpolska | Hacker News Reader

A VC-funded package and project manager for Python projects, written in Rust, and without involvement of the Python Packaging Authority (PyPA). If Python is too slow or otherwise not good enough to write a good Python package manager in, why use Python altogether?

Using Rust enables uv to install Python interpreters. That feature uses unofficial third-party binary builds. There are no official binary builds for Linux, but there are such builds for Windows and macOS, yet they use the unofficial third-party builds on those platforms as well. Still, I would consider package and project management to be a separate feature from Python management, and I’d leave it to a different tool (which may be the system package manager on some platforms).

View on HN

> without involvement of the Python Packaging Authority (PyPA)

The PyPA does not really exist. The closest to an actual "authority" is the packaging forum on discuss.python.org and the astral folks are active there, see for instance the recent threads on the lockfile standard or the dynamic metadata issue.

> If Python is too slow or otherwise not good enough to write a good Python package manager in, why use Python altogether?

People use Python, Astral exists to solve problems of Python people. I'm not sure what the language they are using to write the tool in is relevant. numpy, scipy, tensorflow and many other cornerstones of Python are written in C, C++ and other non Python languages.

> but there are such builds for Windows and macOS

As the author of Rye where I tried very much the same I can attest that the macOS builds are useless for the uv usecase. It's great that Astral is now maintaining the standalone builds which have become a cornerstone for many Python users over the last three years. We have based our entire development environments on those, even though we have not adopted either rye or uv at our company.

I would argue Astral's products are in a substantively different category (developer tools) than numpy or scipy (numerical libraries), and the constraints on them are significantly different (e.g. like crypto code, you shouldn't roll your own numerical code, and instead use trustworthy libraries, which is what numpy/scipy wrap). Everything from their choice of language to which libraries to depend on (and which ones to make optional) to their installation system has been about being conservative and ensuring that the bootstrap process is as painless as possible for Python-only devs.

Astral to me seem to be targeting a small subset of the community, and their ignorance of the needs outside of it make me very wary of adopting their tools.

I primarily use Rust at my job (and love it) but I still write most of my scripts, benchmarking code etc in Python.

Python is a great scripting language and a great language to wrap other stuff. I have other projects in Python that wrap many packages, some in C++/Rust and working on Python is a lot more fun than most of these languages.

When I'm writing this sort of code, I don't have to `.into()`, derive send/sync/debug/whatever, I don't have to `.clone()` my strings when I pass them to multiple places that accept `String`, I don't have to do oh so many things that make my production/critical code better but I care about very little when I'm writing scripts.

I'm much more effective in my 80:20 in Python than in rust though admittedly I'm still on Poetry since uv is releasing vey quickly and my things work "well enough".

(In package management land - I still think most ecosystems haven't caught up to JavaScript + Rust and Python's module systems have weirdness (mod.rs/__init__.py which is unnecessary) but Cargo _is_ overall really nice).

I couldn't care less in which language it is written, as long as it solves my problems with Python. And uv absolutely does.

> Using Rust enables uv to install Python interpreters.

A Python workflow tool written in Python could equally well install every Python interpreter except for the one it itself is using. Those tools generally work fine with any recent installation, and getting one of those is normally not difficult. On Windows the official builds have standalone installers, and Linux normally comes with Python - an isolated development environment (that won't ever mess with the OS) is at most `apt install python3-pip` plus a `venv` invocation away.

But I'm equally well not going to reject a Python tool because it isn't written in Python. (Of course, if it requires installing a massive runtime that I don't already have, or if the compiled binary is larger than an entire Python source tarball - as I found to be the case with uv - then yes, that does count against it.)

> Still, I would consider package and project management to be a separate feature from Python management, and I’d leave it to a different tool

I do as well. I don't want an integrated "project management" tool, either. (I quite like the Unix philosophy for dev tasks.) But I do want an integrated Python application and library installer with a smooth experience, and Pipx isn't quite there yet.

> If Python is too slow or otherwise not good enough to write a good Python package manager in, why use Python altogether?

To write things that are not package managers? Are you suggesting not being the right tool for this job implies not being the right tool for any job?

> If Python is too slow or otherwise not good enough to write a good Python package manager in, why use Python altogether?

Not every language needs to be good at every thing. Pythons main advantage is inertia, not the things required for this kind of tooling.

PyPA has the involvement of Microsoft. It’s not a big deal, but unlike this it has the negative of GitHub being emphasized every time package publishing is brought up. I don’t see any negatives from having the choice of uv, and it’s a lot smaller of an entity than Microsoft.

> Using Rust enables uv to install Python interpreters.

It could be built with Python and ship with a standalone Python interpreter to bootstrap though.

More likely, it’s easier to write fast and correct Rust code.

Reply on news.ycombinator.com