A basic @fastapi.tiangolo.com app, just one command away. 🎁
First FastAPI thing from @savannah.dev ! 🙌
Also, @crmarsh.com 's uv is awesome, use it. 😎
10.11.2025 23:12
👍 17
🔁 2
💬 0
📌 0
A basic @fastapi.tiangolo.com app, just one command away. 🎁
First FastAPI thing from @savannah.dev ! 🙌
Also, @crmarsh.com 's uv is awesome, use it. 😎
Thank you!
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 👇👇👇
astral.sh/pyx
The goal of pyx is to meet that growing demand and growing complexity.
The amount of Python code in the world is exploding, and packaging is only becoming more critical.
Increasingly, Python packages not only contain native code, but are built for specialized specialized software and hardware.
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.
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.
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.
From that perspective, pyx is just the first piece in a broader vision to build the Astral platform: our next-generation infrastructure for Python.
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.
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.
"Why did the latest setuptools release break our build? Can't we harden against that?"
"Why is everyone on my team re-building the same packages over and over again on their machines?"
"Why is it so hard to install PyTorch, or CUDA, or libraries like FlashAttention or DeepSpeed that build against PyTorch and CUDA?"
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...
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.
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.
Get in touch today 👇👇👇
astral.sh/pyx
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".
I think “selling point” is a bit strong. To me it’s more “an interesting thing that wasn’t true before.”
One underrated implication here: we can now build and publish your package without running or even installing Python.
In pure Rust, we can build your Python package, install it, publish it to a registry, etc.
Try it out by setting your project's build system, or running `uv init --build-backend uv`:
```toml
[build-system]
requires = ["uv_build>=0.7.19,<0.8.0"]
build-backend = "uv_build"
```
(In a future release, we'll make this the default.)
The uv build backend is now stable, and considered ready for production use.
An alternative to setuptools, hatchling, etc. for pure Python projects, with a focus on good defaults, user-friendly error messages, and performance.
When used with uv, it's 10-35x faster.
Amazing!
Thanks Adam!
...plus Brent Westbrook and Dhruv Manilawala :)
And second: thank you (and congratulations) to the folks on the Astral team that made this release possible: @alexwaygood.bsky.social, @burntsushi.net, @carljm.me, @dcreager.net, @gankra.bsky.social, @ibraheem.ca, @michareiser.bsky.social, @sharkdp.bsky.social, @zanieb.bsky.social...
Like Ruff and uv, we're building this project in the open alongside a community of contributors -- over a thousand PRs in total across 30+ authors.
So first: thank you to everyone that's contributed to ty over the past few months!
From here, we'll be implementing the rest of the typing spec, and iterating closely with users as we push towards a production-ready release.
If you're interested in helping us get there, give it a try :)
Over the past few months, we've focused on:
1. Defining the core architecture (highly incremental, to power a language server -- built on the same underlying engine as rust-analyzer).
2. Implementing a bunch of type system features (e.g., generics, overloads, protocols).