iiinova — where your digital self keeps evolving

A Python-native package registry from the creators of uv.

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

astral.sh

pyx | Astral

060

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.

150

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.

150

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...

240

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.

190

A Python-native package registry from the creators of uv.

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

astral.sh

pyx | Astral

280

Charlie Marsh @crmarsh.com · 04/07/2025

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".

417237

I think “selling point” is a bit strong. To me it’s more “an interesting thing that wasn’t true before.”

050

Charlie Marsh @crmarsh.com · 03/07/2025

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.

4632

Charlie Marsh @crmarsh.com · 03/07/2025

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.)

2330

Charlie Marsh @crmarsh.com · 03/07/2025

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.

523643

...plus Brent Westbrook and Dhruv Manilawala :)

0130

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...

1240

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!

1101

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 :)

190

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).

170

Alongside the preview release, we're also shipping an official VS Code extension. And you can use `ty server` directly in any editor that supports the Language Server Protocol (Neovim, etc.).

1150

Like Ruff and uv, ty is open-source and MIT-licensed, so you can use the same tool on the command line, in CI, in any editor, across your team, etc.

190

Instead, this release is about giving users a _preview_ of what to expect from ty, and a call to follow along as we work towards a stable release later this year.

180

With the preview release, we don't expect ty to be usable in production. It's feature-incomplete, and you should expect to encounter bugs or even fatal errors.

1100

Our goal with ty is to build the best static analysis toolchain for Python -- to push the boundaries of how helpful a type checker can be in a highly dynamic ecosystem. And we want it to be capable of scaling to tens or even hundreds of millions of lines of code.

1150