Ruff wasn't named after the bird, we just think it's funny that Charlie didn't know it was a bird. He made up the word :)

I've always assumed it was something like:

ruff - "RUst Formatter".

ty - "TYpe checker"

uv - "Unified python packaging Versioner"? or "UniVersal python packaging"

Also note that R, U and T are one letter away to spell Rust.

Ah, thanks for demystifying!

This is also documented at https://github.com/astral-sh/ty?tab=readme-ov-file#contribut... and https://github.com/astral-sh/ty/blob/main/CONTRIBUTING.md#re...

As noted in the linked issue

> At time of writing, many of the remaining rules require type inference and/or multi-file analysis, and aren't ready to be implemented in Ruff.

ty is actually a big step in this direction as it provides multi-file analysis and type inference.

(I work at Astral)

Are you guys planning to tackle Python debugging next? pydevd could really use a fast native rewrite targeting modern Python.

You're upset that uv doesn't yet support something that no other tool in the ecosystem supports?

I'd love for uv to lock build dependencies, but due to the dynamic nature of Python package metadata it's quite a hard problem. It'll be supported eventually though.

(I work on uv)

I'm just saying uv isn't "it", the packaging issue in Python isn't solved yet.

And yes, build dependencies is the big elephant of why Python packaging sucks.

It's intentionally distinct from the `uv tool` interface — it won't change `ruff` or `uv tool run` behaviors.

Please open an issue with some details about the memory usage. We're happy to investigate and feedback on how it's working in production is always helpful.

(I work on uv)

Last time I looked into this I found this unresolved issue, which is pretty much the same thing: https://github.com/astral-sh/uv/issues/7004

We run on-prem k8s and do the pip install stage in a 2CPU/4GB Gitlab runner, which feels like it should be sufficient for the uv:python3.12-bookworm image. We have about 100 deps that aside from numpy/pandas/pyarrow are pretty lightweight. No GPU stuff. I tried 2CPU/8GB runners but it still OOMed occasionally so didn't seem worth using up those resources for the normal case. I don't know enough about the uv internals to understand why it's so expensive, but it feels counter-intuitive because the whole venv is "only" around 500MB.

Thanks that's helpful.

Did you try reducing the concurrency limit?

Thanks for the feedback!

The combination of

– “client (uv) and server (pyx)” and

– “You can use it to host your own internal packages, or as an accelerated, configurable frontend to public sources like PyPI and the PyTorch index.”

is what really helped me understand what pyx aims to be.

I would also put this list of issues that this fixes higher. It makes it more obvious what the point is. (And also a setuptools update literally broke our company CI last week so I was like "omg yes" at that point.)

Yes, we let you override our detection of your hardware. Though we haven't implemented dumping detected information on one platform for use on another, it's definitely feasible, e.g., we're exploring a static metadata format as a part of the wheel variant proposal https://github.com/wheelnext/pep_xxx_wheel_variants/issues/4...

It's actually not powered by Wheel Variants right now, though we are generally early adopters of the initiative :)

Well it was just a guess, "GPU-aware" is a bit mysterious to those of us on the outside ;).

We're hoping that building a commercial service makes it clear that we have a sustainable business model and that our tools (like uv) will remain free and permissively licensed.

(I work at Astral)

I think having a credible, proven business model is a feature of an open source project - without one there are unanswered questions about ongoing maintenance.

I'm glad to see Astral taking steps towards that.

I've been wondering where the commercial service would come in and this sounds like just the right product that aligns with what you're already doing and serves a real need. Setting up scalable private registries for python is awful.