OpenAI to acquire Astral

[barry (Barry Warsaw)]

For me, lately, it’s uv-shebang + PEP 723 + [tools.uv.sources] with editable = true. Although I tend to use a $PATH python3 executable, PBS is probably another great addition here.

[notatallshaw (Damian Shaw)]

@pf_moore

The one genuine problem here is that because uv is implemented in Rust rather than Python, we can’t directly reuse code or libraries from uv in other tools in the ecosystem. Instead, we’ll have to reimplement the functionality in Python first. But that’s not a problem with the acquisition, it’s something that was inherent in the choice to implement uv in Rust in the first place.

One nitpick, that’s really only true for pip and tooling leveraging pip as a packaging installer, nothing stops other Python packaging ecosystem tooling (hatch, Poetry, PDM etc.) from using Rust or even packaged or vendored parts of uv’s code.

@barry

For me, lately, it’s uv-shebang + PEP 723 + [tools.uv.sources] with editable = true. Although I tend to use a $PATH python3 executable, PBS is probably another great addition here.

I think the editable feature here is unique to uv?

hatch already supports a shebang + PEP 723, or a workspace feature that handles editable local dependencies in pyproject.toml, but not PEP 723 + editable dependencies.

Not something I’d ever thought about before, I assume hatch + others could add it given they’re most the way there already, if the feature was requested and there is the developer/maintainer support to implement.

[Lucas_Malor]

@pf_moore

We can debate which approach is “better”

Oh no, I pass. Just remembered something happened to me in past. I’m not a dependency expert, so I’ll take your word for it.

@pf_moore

Yes, you can do pip cache purge.

It’s not the same. uv cache prune only removes no more used cache.
But maybe pip can’t do that now. Probably only when it implements the hard/sym link strategy.

@pf_moore

we can’t directly reuse code or libraries from uv in other tools in the ecosystem.

@notatallshaw

that’s really only true for pip and tooling leveraging pip as a packaging installer

Why can’t pip integrate Rust code?

@jamestwebber

I’ll just chime in and point out that I didn’t say such a thing either. Please be more careful when attributing opinions to others

Yeah. I don’t know how I confused installer with package/project manager.

[barry (Barry Warsaw)]

@notatallshaw

I think the editable feature here is unique to uv?

I believe so, noting the [tool.uv.sources] TOML section, but that does seem like a feature ripe for standardization.

@notatallshaw

hatch already supports a shebang + PEP 723, or a workspace feature that handles editable local dependencies in pyproject.toml, but not PEP 723 + editable dependencies.

Yep, and the editable sources thing might be a bit niche, although for my use cases, very handy. Let’s say you’re developing a library that has some top level scripts. You can install it and the entrypoints get materialized. Or, since I use hatch, I can execute them through hatch because they live in hatch-managed venvs. But there are some cases where I’ve needed a top-level entrypoint script that calls into the library from a git repo checkout. That’s where the editable bit comes in super handy.

[cjames23 (Cary Hawkins)]

@notatallshaw

Not something I’d ever thought about before, I assume hatch + others could add it given they’re most the way there already, if the feature was requested and there is the developer/maintainer support to implement.

I intend to close that gap at some point this year in hatch. There was just a lot of work with workspace support that needed to be completed first.

[pf_moore (Paul Moore)]

@Lucas_Malor

Why can’t pip integrate Rust code?

Because we need a single wheel that can be used on all platforms. Which in turn is due to the logistics of shipping pip via ensurepip and get-pip.py. Native code prohibits that.

Also, the Rust code in uv isn’t packaged as importable Python extensions, so there would be work needed to do that even if we were talking about Python code that didn’t have the unique constraints that pip does.

[henryiii (Henry Schreiner)]

@barry

noting the [tool.uv.sources] TOML section, but that does seem like a feature ripe for standardization.

This would be really great to standardize, but it’s also really hard to standardize; it’s the thing that varies the most between build backends, and is the core reason to select some of them (flit-core/uv_build vs. hatchling, for example). I’d like a mechanism that supported both styles, but even an explicit-only one would be useful (just not as beginner friendly). But there’s also stuff like auto-excluding things like .pyc that makes it tricky.

I also think workspaces are likely a good thing to standardize. (I still need to learn to use them, but I’ve used them with Cargo in Rust, and those are great.)

Back to the main topic, my thoughts:

• Using these tools (ruff/uv/ty) is fine for now. No need to fork today, and Astral is pouring in much more paid development time than any fork could get, so it’s going to be better than a fork. (Personally, as long as the current team is mostly intact, I don’t think that will be a problem, but I could see everyone being moved and then something bad happening).
• It’s possible there might starting being problems in the future, at which time people could get together and fork an OSS version. The license allows it, which is the important thing.
• uv is making Python-based tooling better already. For example, pip gained the ability to limit package selection to a date. Pip/packaging is getting faster. Hatch got workspace support.
• Most of uv’s developments around UX can be implemented now that they have been pioneered - that is, uv run is amazing, but we could implement that (in fact, there’s a big downside to uv run: it engages the locking solver, and that can surprise people as it’s an advanced topic with odd behaviors. If hatch or something implemented it, we could either not have a locking solver or have a way to turn it off). The key feature of uv run is that it installs the dev group automatically, with no uv-specific configuration at all. A lot of it comes from copying Cargo in Rust, actually.
• Speaking of that, almost every project I work on supports uv run out of the box, as I use that all the time locally (and it’s great with AI models, too). But I have nearly zero uv-specific configuration, it’s all done via standards (dependency-groups). The more we can standardize, the better it will be for moving between tools, and picking the best tool and developing the best tool.
• A lot of money has gone to paying the best developers to work full time on the tools at Astral, which is why they are great. I’ve been worried about how they would continue this (the memory of textualize failing is still fresh!), so hopefully this will be great; other similar acquisitions have gone well (GitHub, for example). Yes, some don’t. But I’m hopeful. I wish developer experience was something more people valued. IMO, it’s the key difference between languages like Python, Rust, and Go and “classic” languages like C, C++, and Fortran. I am happy to write C++, but shipping an app in C++ is way, way harder than Rust or Python. C and C++ dependencies are atrocious. That’s why pybind11 and CLI11 are header only. They would compile so much faster if not, but it’s just not reasonable to ship.

[brettcannon]

@notatallshaw

@rtpg

-build-standalone (currently maintained by Astral since uv relies on it) is a non-trivial amount of work, if it were 3 shell calls and that’s it then we’d be good.

Now… maybe CPython needs to get to a level where python-build-standalone basically doesn’t need to exist.

I agree, Astral identified it as key dependency and took over maintainership, they’ve been a good open source community participant and upstreamed many of the patches. I do think thie PSF/Steering Council/Core Developers should evaluate producing their own version, if at least for the bugfix of each release.

I’m working on it (and have been since October). It’s been on pause waiting for Astral to upstream their patches after I gave them all an initial review at the end of January. I have a PEP that I’m about to go public with, and once that’s done I’m pivoting back to working on prebuilt, relocatable builds for CPython that will come from python.org.

[sirosen (Stephen Rosen)]

@henryiii

@barry

noting the [tool.uv.sources] TOML section, but that does seem like a feature ripe for standardization.

This would be really great to standardize, but it’s also really hard to standardize; it’s the thing that varies the most between build backends, and is the core reason to select some of them (flit-core/uv_build vs. hatchling, for example). I’d like a mechanism that supported both styles, but even an explicit-only one would be useful (just not as beginner friendly). But there’s also stuff like auto-excluding things like .pyc that makes it tricky.

I need to learn more about this feature-set in uv, but last year I was trying to work something out with similar properties.^[1] Zanie kindly pointed me towards the uv table for inspiration.

I think we should consider this “concrete dependency metadata”, bridging the abstract/concrete divide. (Perhaps that understanding is too naive; I haven’t studied it in a while.)

tool.uv.sources is a great example of how we’re in a much better place today than before Astral’s work started. We now have a better vocabulary around and understanding of parts of the packaging problem space. That holds even if the Astral team were dissolved today and no fork were created of their tools.

---

For all of the worry about how this impacts the rest of the community, my primary concern is about how this impacts the Astral team members themselves.

They are now working for a larger and much more controversial company, and they have to balance a number of social pressures. I wish them all the best.

---

1. my interest is in local path dependencies, e.g., to target “.” ↩︎