Today, we're announcing our first hosted infrastructure product: pyx, a Python-native package registry.
We think of pyx as an optimized backend for uv: it’s a package registry, but it also solves problems that go beyond the scope of a traditional "package registry".
pyx is now live with our early partners, including Ramp, Intercom, and fal.
As we work towards GA, we're looking for more early users to help shape the future of Python infrastructure.
With pyx, uv becomes even faster, more secure, and hardware-aware (PyTorch, CUDA, FlashAttention, etc. become first-class citizens).
You can use pyx to host private packages (it's much faster than other private registries), or as a frontend to public sources like PyPI.
Much of the inspiration for pyx comes from the classes of problems we see in the uv issue tracker that we can't solve with a client alone -- but could solve with a server. For example...
"Why is it so hard to install PyTorch, or CUDA, or libraries like FlashAttention or DeepSpeed that build against PyTorch and CUDA?"
"Why is everyone on my team re-building the same packages over and over again on their machines?"
"Why did the latest setuptools release break our build? Can't we harden against that?"
With pyx, we can solve these problems.
And for me, that's the most exciting thing about it. By providing our own end-to-end infrastructure we can solve _so_ many more problems for users that used to be out-of-scope.
A "private registry" typically connotes security, compliance, etc.
pyx gives you those things, but the ideas behind it are actually much bigger. pyx is about improving the developer experience of working with Python. Solving user problems with our own infrastructure.
From that perspective, pyx is just the first piece in a broader vision to build the Astral platform: our next-generation infrastructure for Python.
Our deep focus on Python enables us to build better Python infra than anything else out there; and integration with our open source tools enables us to build experiences that otherwise wouldn't be possible at all.
You won't need to use pyx to use uv, and you won't need to use uv to use pyx. But when used together, entire classes of problems disappear.
pyx is also a good example of our strategy and philosophy.
Our tools remain free, open source, and permissively licensed. Nothing changes there. Instead, we want to offer hosted services that represent the "natural next thing you need" when you're already using our tools.
The amount of Python code in the world is exploding, and packaging is only becoming more critical (whether for humans, or agents, or whomever).
Increasingly, Python packages not only contain native code, but are built for specialized specialized software and hardware.
The goal of pyx is to meet that growing demand and growing complexity.
pyx is not yet generally available -- we're a small team, iterating on the product with early partners.
If you're interested in the future of Python, if these problems resonate with you, or even if you're just a fan of our work: get in touch today 👇👇👇
We’re building a new static type checker for Python, from scratch, in Rust.
From a technical perspective, it’s probably our most ambitious project yet. We’re about 800 PRs deep!
Like Ruff and uv, there will be a significant focus on performance.
The entire system is designed to be highly incremental so that it can eventually power a language server (e.g., only re-analyze affected files on code change).
Performance is just one of many goals, though.
For example: we're investing heavily in strong theoretical foundations and a consistent model of Python's typing semantics.
(We're lucky to have @carljm and @AlexWaygood on the team for many reasons, this is one of them.)
python-build-standalone has exploded in popularity, with over 70M downloads all-time.
But what is a "standalone" Python build?
It wasn't obvious to me at first! Initially, I didn't understand what problem was being solved or why it mattered...
First, some context on the problem.
Normally, when you build CPython on Linux or macOS, several system paths are hardcoded into the binary.
This is fine if you're building and installing Python on a single machine... but it's a problem if you want to pre-build Python and then distribute it to other machines, since those paths might be wrong!
Today, we're shipping a series of features that move uv beyond a pip alternative, and into an end-to-end solution for managing Python projects, command-line tools, single-file scripts, and even Python itself.
A collection of (sometimes contradictory) beliefs I've developed on building fast software...
Sometimes, performance just doesn't matter. If I make some codepath in Ruff 10x faster, but no one ever hits it, I'm sure it could get some likes on Twitter, but the impact on users would be meaningless.
And yet, it's good to care about performance everywhere, even when it doesn't matter. Caring about performance is cultural and contagious. Small wins add up. Small losses add up even more.
There's an extremely interesting conversation going on in Python right now around the future of performance.
It's centered on @colesbury's PEP 703, which makes the GIL optional (to be removed entirely in the future), but comes at a cost.
Here's my summary...
For context: The CPython interpreter isn't thread-safe, so the global interpreter lock ("GIL") exists to ensure that only one thread is actually executing code at a time.
PEP 703 includes changes to (1) make the interpreter thread-safe and (2) make the GIL optional.
It's agreed that removing the GIL would have an enormous performance benefit on multithreaded code. It would change Python dramatically.
But there appear to be two main hesitations to the PEP.