# OpenAI to acquire Astral **URL:** \ **Category:** Developer Tools\ **Created:** [March 19, 2026, 8:19pm UTC](https://discuss.python.org/t/openai-to-acquire-astral/106605 "2026-03-19T20:19:21Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![jamestwebber](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jamestwebber/32/12799_2.png) [@jamestwebber](https://discuss.python.org/u/jamestwebber)\ **Post date:** [March 20, 2026, 6:22pm UTC](https://discuss.python.org/t/openai-to-acquire-astral/106605/22 "2026-03-20T18:22:31Z")
> [@Kwpolska](#): > > Oh well, Rust is super fast, who cares about sustainability or maintainability, a VC-funded company will be around forever and never do anything against the users, right? I’d argue that this applies to open source projects, too–many important projects are one burned-out maintainer away from shutting down. One long-lasting impact of `uv` is that it moved the packaging discussion from “what should `pip` do” to “what should _installers_ do”. There were other projects in the space, but none as impactful as `uv`. I think that was valuable even if `uv` doesn’t continue to develop\[1\]. I view Astral’s contribution similar to how I think of the `faster-cpython` project\[2\] or Meta devoting resources into the nogil work. A corporation decided it was worth it to invest in the Python ecosystem–not entirely altruistically, but not entirely to advance their own goals. That’s fine. We don’t have to get mad about it when that inevitably ends. * * * 1. and I still think it will for some time 2. funded by Microsoft for a bit, then shut down ---
**Author:** ![notatallshaw](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/notatallshaw/32/10861_2.png) [@notatallshaw](https://discuss.python.org/u/notatallshaw)\ **Post date:** [March 20, 2026, 7:11pm UTC](https://discuss.python.org/t/openai-to-acquire-astral/106605/23 "2026-03-20T19:11:24Z")
I see a lot of posts here worried particularly about uv as a foundational Python packaging tool, I think it’s worth taking a step back and looking at what it offers that are people are worried about, and considering investing directly in existing tooling to help catch up: 1. Speed installing packages: This is significantly driven from uv’s cache mechanism, where packages are installed to a cache and then linked to inside a venv, that could be [added to pip](https://github.com/pypa/pip/issues/11092), or your Python package managers of your choice. 2. Fast metadata/version handling: well we’ve been making significant progress in `packaging` to speed up metadata handling, 26.0 significiantly improved things and since then Henry added automatic [benchmarking](https://github.com/pypa/packaging/pull/1059) and we’ve made even more progress on performance. Before 26.2 I plan to land a new implementation of filtering Versions which for complex specifiers should be more than 10x faster. And there’s a lot more that could be done, an option for a global Version cache, native code implementations, have the standard library provide very stable parts of Version parsing, PRs welcome. This benefits all tools that use `packaging`. 3. More advanced resolver algorithm: I’m working directly on this right now to help pip catch up here. I hoping to integrate this directly into `resolvelib`, but it’s possible we will need a new resolver library. I am working on speed, but there is also the aspect of “universal” resolution, which is what may require a new library. 4. Lock files: We have a standard lockfiles that [pip can generate](https://pip.pypa.io/en/stable/cli/pip_lock/), then next step is being able to install from them, work is progressing there also. 5. Syncing: pip-tools offers this but I think pip should have native support, especially with lock files, [an issue is open](https://pip.pypa.io/en/stable/cli/pip_lock/) and I would review a PR or eventually add it myself. 6. Workflows: This is already provided by many tools for different use cases, such as Poetry, hatch, pdm, etc. 7. All in one tool: Some of the workflow tools are already all in one, but nothing stops someone from wrapping the libraries they think are best into a single CLI. I’m not suggesting people stop using uv or investing into it, I’m just not so sure it’s the only tool that offers most of those conveniences, or that we couldn’t fairly quickly add those conveniences. ---
**Author:** ![sinoroc](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/sinoroc/32/1607_2.png) [@sinoroc](https://discuss.python.org/u/sinoroc)\ **Post date:** [March 20, 2026, 7:12pm UTC](https://discuss.python.org/t/openai-to-acquire-astral/106605/24 "2026-03-20T19:12:57Z")
> [@jamestwebber](#): > > moved the packaging discussion from “what should `pip` do” to “what should _installers_ do”. Probably an irrelevant detail but this was true long before `uv` showed up. To me lately, it rather felt like the trend was going more and more towards “what should `uv` do” instead of “what should _installers_ do”. I hope this will be an incentive for people to try out Hatch, PDM, Poetry, and others. * * * Most of all I wonder what is going to happen to `python-build-standalone`\[1\]. Lately it has felt like a bunch of tools and systems were considering adopting `python-build-standalone`. I wonder how this will turn out. * * * 1. this is still a far stretch but it could be a better comparison to the Bun situation ---
**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\ **Post date:** [March 20, 2026, 8:43pm UTC](https://discuss.python.org/t/openai-to-acquire-astral/106605/25 "2026-03-20T20:43:25Z")
> [@jamestwebber](#): > > One long-lasting impact of `uv` is that it moved the packaging discussion from “what should `pip` do” to “what should _installers_ do”. There were other projects in the space, but none as impactful as `uv`. I think that was valuable even if `uv` doesn’t continue to develop . IMO this is very true. There were always other installers like PDM and Poetry, but the narrative never really moved beyond pip as “the installer” until `uv` started gaining traction. I do hope we can retain that change in perspective. Also, another lasting impact of `uv` is the clear demonstration of what well-funded development can bring to the packaging ecosystem. Whatever the results of the acquisition, `uv` has made huge progress in an amount of time that previously we would have considered impossible. If we could use this experience to motivate future investment in packaging tools, that would be another big win. Again, regardless of what the future holds for `uv` itself. > [@sinoroc](#): > > Most of all I wonder what is going to happen to `python-build-standalone` . Lately it has felt like a bunch of tools and systems were considering adopting `python-build-standalone`. I wonder how this will turn out. I think there’s work going on to bring `python-build-standalone` under the “core Python” umbrella somehow. Initially, I think it was motivated by the fact that it was a one-person project and important enough that we wanted to reduce the risk associated with that. I don’t know if astral becoming involved took some of the pressure off the core to be directly involved, but I hope that post-acquisition it becomes a goal to get `python-build-standalone` hosted on [python.org](http://python.org) somehow. I believe it would be a real problem to have a key\[1\] binary distribution owned by a single company - especially one with the sort of public perception that OpenAI has. * * * 1. It’s used by a _lot_ of packaging tools, I believe ---
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [March 20, 2026, 10:23pm UTC](https://discuss.python.org/t/openai-to-acquire-astral/106605/26 "2026-03-20T22:23:59Z")
> [@JamesParrott](#): > > And going back to pip and venv or something, is a simple option, especially now we have PEP751 pylock.toml files. And I’m continuing to work on standards and such so that a baseline workflow can be based on standards. Add on the perf work in pip that Damian covers in [OpenAI to acquire Astral - #23 by notatallshaw](https://discuss.python.org/t/openai-to-acquire-astral/106605/23) and I’m hopeful uv usage will feel like a choice and not a requirement to anyone. > [@pf\_moore](#): > > I think there’s work going on to bring `python-build-standalone` under the “core Python” umbrella somehow. There is and I’m effectively leading it. I kicked it off in October last year after the core dev sprints. > [@pf\_moore](#): > > I don’t know if astral becoming involved took some of the pressure off the core to be directly involved No, and in fact Astral has always supported the idea of upstreaming things so PBS doesn’t have to carry patches. Unfortunately they have been so busy since I started the work that they haven’t had time to push anything upstream lately. But I’m planning to push on regardless. ---
**Author:** ![Tinche](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/tinche/32/12507_2.png) [@Tinche](https://discuss.python.org/u/Tinche)\ **Post date:** [March 20, 2026, 11:02pm UTC](https://discuss.python.org/t/openai-to-acquire-astral/106605/27 "2026-03-20T23:02:16Z")
You missed the single best part of uv (for me but also for others in my circle): the fact that uv does not run on Python so can be used to bootstrap and manage Python 🙂 (Then, add all other others you mentioned.) ---
**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\ **Post date:** [March 20, 2026, 11:12pm UTC](https://discuss.python.org/t/openai-to-acquire-astral/106605/28 "2026-03-20T23:12:37Z")
> [@Tinche](#): > > You missed the single best part of uv (for me but also for others in my circle): the fact that uv does not run on Python so can be used to bootstrap and manage Python Agreed, although like many of the other points @notatallshaw noted, it’s not exclusive to uv (or even to the fact that uv is not written in Python). We could certainly implement a tool like pip using an embedded Python interpreter so that it would look like a standalone executable, uv-style. It’s just that existing tools haven’t taken that approach. Changing pip (for example) to be a standalone executable using an embedded Python interpreter and acting on the user’s Python environment without being installed into it would be a substantial change in architecture, probably big enough to need funded resource to achieve it. But it’s certainly not impossible, if the lesson from uv is that it’s a better approach. And of course, _new_ tools don’t have the constraints that existing ones do, so could take that approach much more easily. IMO, the packaging community should be investing a lot more effort into improving things around building and deploying standalone applications, _including_ this sort of bundling. But I’ve said that before, and I don’t think it’s worth having that debate here. Suffice it to say that it’s certainly possible\[1\]. * * * 1. The new Python manager for Windows uses exactly this sort of approach, for example. ---
**Author:** ![notatallshaw](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/notatallshaw/32/10861_2.png) [@notatallshaw](https://discuss.python.org/u/notatallshaw)\ **Post date:** [March 20, 2026, 11:14pm UTC](https://discuss.python.org/t/openai-to-acquire-astral/106605/29 "2026-03-20T23:14:34Z")
> [@Tinche](#): > > You missed the single best part of uv (for me but also for others in my circle): the fact that uv does not run on Python so can be used to bootstrap and manage Python 🙂 (Then, add all other others you mentioned.) Given Python runs in more places than uv I think if you put in enough time and effort to building a good installer it could be better than uv. e.g. have an installer set up like uv, `curl ... | sh`, and it installs it’s own private copy of Python, and then you use that to run your Python packaging tool. ---
**Author:** ![rtpg](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/rtpg/32/14068_2.png) [@rtpg](https://discuss.python.org/u/rtpg)\ **Post date:** [March 22, 2026, 4:38am UTC](https://discuss.python.org/t/openai-to-acquire-astral/106605/30 "2026-03-22T04:38:44Z")
If it were easy to “just” install a private copy of Python off the shelf… `python-build-standalone` (currently maintained by Astral since `uv` relies on it) is [a non-trivial amount of work](https://github.com/astral-sh/python-build-standalone), 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. Just really isn’t just a question of running existing installers. I think it would be nice if existing installers could absorb as much of this work as possible to make it possible though! ---
**Author:** ![Lucas\_Malor](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/lucas_malor/32/24845_2.png) [@Lucas\_Malor](https://discuss.python.org/u/Lucas_Malor)\ **Post date:** [March 22, 2026, 11:35am UTC](https://discuss.python.org/t/openai-to-acquire-astral/106605/31 "2026-03-22T11:35:40Z")
> [@henryiii](#): > > [Thoughts on OpenAI acquiring Astral and uv/ruff/ty](https://simonwillison.net/2026/Mar/19/openai-acquiring-astral/) Ty for sharing that! It’s clear now the acquisition: they want an uv (pyx) with GPU steroids, that’s really cool for AIs. > [@notatallshaw](#): > > I think it’s worth taking a step back and looking at what it offers that are people are worried about This is a really good news! But `uv` it’s not just a faster and less hard disk hungry pip – since it uses hard links or soft links when possible. As @jamestwebber and@pf\_moore pointed out, it’s a better instaler package manager. And I can add it’s not _only_ a better installer package manager. With uv you can install different versions of python, use `uv tool`, `uvx` and `uv venv`. It’s one ring to rule them all, and it’s officially supported by pycharm. I love pip and pipx. And the first times I just used uv as a faster pip. But now I’m using it for all my new projects, because it’s not simply faster than venv + pip + pipx + poetry + \*args, \*\*kwargs, it’s much more simple. A really game-changer will be something like maven, that doesn’t need venvs. Venvs are a really difficult beast, and for newbies a big entry barrier that they avoid – as I did – until nothing more works. But probably this will be an _huge_ change in all python ecosystem. ☹ > [@JamesParrott](#): > > As long as OpenAI don’t insist on integrating their equivalent of Copilot into it, this could even be good news for the future of uv. Indeed IMHO it’s premature FUD. But maybe this fear can move people to improve the current available tools. And that’s good! 🙂 > [@Kwpolska](#): > > you need to find a group of people who are (a) passionate about Python packaging, (b) fluent in Rust, and (c) not already employed by Astral (a) is satisfied by a lot of people. Many of these posted in this thread 😉 (b) is not strictly necessary, even if it will be better (c) why? The history is full of people that left a company and created a similar or identical project. See mariadb, Libreoffice or the X programmers that moved to Meta. But I’m not a lawyer, and this kind of things give me a headache X-D ---
**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\ **Post date:** [March 22, 2026, 12:32pm UTC](https://discuss.python.org/t/openai-to-acquire-astral/106605/32 "2026-03-22T12:32:18Z")
> [@Lucas\_Malor](#): > > As @jamestwebber and@pf\_moore pointed out, it’s a better instaler Hang on, where did I say that? You’re misinterpreting my comments here. The `uv pip` command is basically pip, but with improvements that could be made because `uv` had a funded development team working full time on it. That’s “better” in a certain sense, but not in any insurmountable way. And similarly, I believe the rest of the `uv` interface is what other tools like PDM, Poetry and Hatch could achieve\[1\] with funding and more development resource. Money doesn’t solve everything, but it helps a lot with some things 🙂 * * * 1. If they wanted to - workflow tools are notoriously opinionated and there’s no “one size fits all”. ---
**Author:** ![Kwpolska](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/kwpolska/32/10542_2.png) [@Kwpolska](https://discuss.python.org/u/Kwpolska)\ **Post date:** [March 22, 2026, 12:44pm UTC](https://discuss.python.org/t/openai-to-acquire-astral/106605/33 "2026-03-22T12:44:46Z")
> [@Lucas\_Malor](#): > > (b) is not strictly necessary, even if it will be better To maintain an open-source project that is 98.3% Rust ([according to GitHub](https://github.com/astral-sh/uv)), you absolutely need fluent Rust developers. Unless you consider writing a new README and then more-or-less-blindly cherry-picking all commits from upstream to be “maintaining a project”. ---
**Author:** ![JamesParrott](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jamesparrott/32/10534_2.png) [@JamesParrott](https://discuss.python.org/u/JamesParrott)\ **Post date:** [March 22, 2026, 12:55pm UTC](https://discuss.python.org/t/openai-to-acquire-astral/106605/34 "2026-03-22T12:55:45Z")
“fluency” is the minimum bar for working on `unsafe` Rust. Otherwise, the Rust compiler is that good, it’s possible for generally experienced coders who know other system languages, to maintain a Rust project in a usable enough state that users’ pipelines still work. Assuming the maintainers learn more Rust as they go on. I haven’t checked yet which category uv falls under (not feeling any urgency in the slightest to work on a fork yet). ---
**Author:** ![Rosuav](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/rosuav/32/3429_2.png) [@Rosuav](https://discuss.python.org/u/Rosuav)\ **Post date:** [March 22, 2026, 12:56pm UTC](https://discuss.python.org/t/openai-to-acquire-astral/106605/35 "2026-03-22T12:56:48Z")
> [@JamesParrott](#): > > The Rust compiler is that good, it’s possible for generally experienced coders who know other system languages, to maintain a Rust project in a usable enough state that user’s pipelines still work. Assuming they learn more Rust as they go on. That’s true of most languages. Nothing special about Rust there. ---
**Author:** ![JamesParrott](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jamesparrott/32/10534_2.png) [@JamesParrott](https://discuss.python.org/u/JamesParrott)\ **Post date:** [March 22, 2026, 12:59pm UTC](https://discuss.python.org/t/openai-to-acquire-astral/106605/36 "2026-03-22T12:59:06Z")
That’s good to know, but beyond my comfort zone. I’m assuming plenty of other guard rails too, e.g. high test coverage and CI&CD. ---
**Author:** ![notatallshaw](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/notatallshaw/32/10861_2.png) [@notatallshaw](https://discuss.python.org/u/notatallshaw)\ **Post date:** [March 22, 2026, 2:45pm UTC](https://discuss.python.org/t/openai-to-acquire-astral/106605/37 "2026-03-22T14:45:15Z")
> [@rtpg](#): > > If it were easy to “just” install a private copy of Python off the shelf… Please don’t reframe my post as dismissive on the amount of work required, I never "just"ed the difficulty, I wrote “if you put in enough time and effort”. I’m well aware of the difficulty. > [@rtpg](#): > > `-build-standalone` (currently maintained by Astral since `uv` relies on it) is [a non-trivial amount of work](https://github.com/astral-sh/python-build-standalone), 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. > [@Lucas\_Malor](#): > > But `uv` it’s not just a faster and less hard disk hungry pip That’s not even true, if use uv for any period of time you’ll quickly find that uv is _more_ disk hungry than pip, all those old fully expanded installs of packages in uv’s cache you no longer need eat a lot disk space than pip’s wheel cache. > [@Lucas\_Malor](#): > > As @jamestwebber and@pf\_moore pointed out, it’s a better instaler. I’m trying to be constructive and identity what uv does better than other Python packaging installers and what can be done to close the gap, I wish you would do the same, it isn’t help to just say “better”. I will say though, one thing Charlie has repeated often is being faster isn’t just quantitatively better, there becomes a point where a tool is so much faster you can use a tool in a lot more places and it becomes a qualitative improvement. I see no reason other tools can’t learn lessons from uv here. > [@Lucas\_Malor](#): > > With uv you can install different versions of python, use `uv tool`, `uvx` and `uv venv`. It’s one ring to rule them all, and it’s officially supported by pycharm. As far as I’m aware all of those features are supported in subset or whole by hatch, poetry, pipx, and PDM. If you think there’s something missing, please be specific. > [@Lucas\_Malor](#): > > I love pip and pipx. And the first times I just used uv as a faster pip. But now I’m using it for all my new projects, because it’s not simply faster, it’s much more simple. Again that’s vague and unhelpful, I also use uv a lot, and I’m able to point to exactly why, and work on those in other tools. ---
**Author:** ![Lucas\_Malor](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/lucas_malor/32/24845_2.png) [@Lucas\_Malor](https://discuss.python.org/u/Lucas_Malor)\ **Post date:** [March 22, 2026, 3:41pm UTC](https://discuss.python.org/t/openai-to-acquire-astral/106605/38 "2026-03-22T15:41:28Z")
> [@pf\_moore](#): > > Hang on, where did I say that? You’re misinterpreting my comments here. > > The `uv pip` command is basically pip, but with improvements that could be made because `uv` had a funded development team working full time on it. That’s “better” in a certain sense, but not in any insurmountable way. And similarly, I believe the rest of the `uv` interface is what other tools like PDM, Poetry and Hatch could achieve Sorry, I didn’t _only_ misinterpreted your post. I confused _installer_ (pip) with _package manager_ (poetry etc). I will correct that in the original post. I don’t think it’s impossible to par with uv _as an installer_. On the contrary, I think it’s inevitable. But `uv pip` is not just equal to pip. I noticed that they diverge in the way they manage the package conflicts. I remember I had a problem installing from a requirements.txt with pip, and uv had no problems. And indeed searching on their site I found [this doc](https://docs.astral.sh/uv/concepts/resolution/). Furthermore, `uv pip` it’s mainly for compatibility and to lure people like me that used pip by dozen of years to use it “the pip way”. The “uv way” is to create a project and do `uv add`. Is it simply `uv pip` + writing in toml? Dunno. pip can be improved, and I suppose the difference between `uv pip` and `pip` will be irrelevant. But pip is an installer. It’s not poetry, pipx, venv and winget / flatpack. uv is that and more. And uv did a lot of improvements and features quickly in a low level programming language. Honestly, I don’t know very much about the other package managers. I was “old school”: pip + venv + setup.py. I worked a little with poetry because of work. But it didn’t really impressed me. I preferred to continue with the old way, until I discovered uv it’s not just a faster pip. I doubt that poetry will change its interface to make it simpler and to do all what uv does. And that’s good! I prefer a Unix Philosophy: one tool that do one thing very well. But the fact is that in 2026 no one downloads the source code of cat, grep etc, compile them and install them. They download Ubuntu and they have all the zoo. The current tools can be improved, and I will be really happy to see them improving. But I’ll turn back using them? Honestly. I don’t know. Let’s see what will happen. > [@Kwpolska](#): > > To maintain an open-source project that is 98.3% Rust ([according to GitHub](https://github.com/astral-sh/uv)), you absolutely need fluent Rust developers Of course, if you want to fork uv. But pipx and venv can be improved without using Rust _right now_. Never is better 😉 I would be happy to see more people using Rust. I would be happy to see also Rust in Cpython code! AFAIK, Rust now is used also in Linux kernel, and Linus would more people using it. But honestly, is it really needed to write _all the code_ in Rust? Usually, you write in Python and then rewrite the bottlenecks. And you have a lot of options than just using Rust. > [@notatallshaw](#): > > uv is _more_ disk hungry than pip You can do ``uv cache prune`. I don’t know if pip can do it. If not, it will be a great addition! AFAIK, uv doesn’t copy the deps inside the venv. uv caches it and use hard links when possible. This is saves an _incredible_ amount of space, when you have many projects that uses the same packages. And in particular when the packages are big, like SciPy, Tensorflow etc. I don’t know if pip has plans for using hard/sym links when possible. About the rest, I hope I clarified my thoughts 🙂 No one is saying pip is a bad tool. On the contrary! I blessed God when pip came out. Installing python packages before pip was a pain. Side note: I’m just saying my impressions as an end user. No one wants to dismiss dozen of years of hard work for making tools that helped a lot of people like me, made by people that had no money back and maybe sometimes ever a Thank you. That’s the FOSS world baby :'-) I _know_ this feeling. ---
**Author:** ![Lucas\_Malor](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/lucas_malor/32/24845_2.png) [@Lucas\_Malor](https://discuss.python.org/u/Lucas_Malor)\ **Post date:** [March 22, 2026, 4:43pm UTC](https://discuss.python.org/t/openai-to-acquire-astral/106605/39 "2026-03-22T16:43:21Z")
> [@notatallshaw](#): > > As far as I’m aware all of those features are supported in subset or whole by hatch, poetry, pipx, and PDM. If you think there’s something missing, please be specific. That’s the point. You’re an expert in this field. I’m only the end user. 🙂 And as an end user, I used pip, venv, pipx and poetry. I don’t know them extensively, as I don’t know uv extensively too. I know only what matter for my work. My workflow before was: create a venv with `python -m venv venv`, activate it, `pip install` something, use `pip freeze > requirements.txt`. If I needed a tool, I used `pipx`. If I have to update pip, I used `pythonX.Y -m pip update -U pip`. And this was needed, since this way I got rid of the update message 😉 If I need another python version, well… I compiled it X-D It’s “simple” on Ubuntu: you’ve “just” to do some `apt install` before, clone CPython, checkout the right tag, create a separate build dir and do the usual: ```python CC=gccX.Y ../cpython/configure --enable-optimizations --with-lto make -j make altinstall ``` Now? Now I do: ```python uv init something cd something uv add somedep ``` And it’s done. If I need a tool, I use uv tool. If I want to update uv, when I remember to do that, I do `uv self update`. If I need to lock the deps, `uv lock`. If I need pythonX.Y… well, since I know how to compile it, I continue to compile it X-D but sometimes I’m lazy and I install it using uv. You says I can do it with Poetry, hatch and PDM. I know only poetry a little and honestly? I don’t _feel_ the need to use them. I already have all that I ever needed with just uv. I suppose that the problem isn’t just to make pip, pipx, venv and PUT\_THE\_NAME\_OF\_YOUR\_PROJECT\_MANAGER\_HERE. The problem is having them all in a simple and coherent way. Python was a winner also because of its battery included. I suppose the Python ecosystem needs something similar for packages and project management, and something “beyond venvs”. ---
**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\ **Post date:** [March 22, 2026, 4:47pm UTC](https://discuss.python.org/t/openai-to-acquire-astral/106605/40 "2026-03-22T16:47:30Z")
> [@Lucas\_Malor](#): > > I noticed that they diverge in the way they manage the package conflicts. A number of differences come down to the fact that `uv` makes assumptions about package metadata that aren’t supported by standards. That means that they can give a better result on “most” packages, but break on valid, but unusual\[1\] cases. We can debate which approach is “better”, but that’s not the point. > [@Lucas\_Malor](#): > > You can do ``uv cache prune`. I don’t know if pip can do it. If not, it will be a great addition! Yes, you can do `pip cache purge`. Of course, if you purge the cache, you lose the performance benefits the cache gave you. So I don’t see the point you’re making. > [@Lucas\_Malor](#): > > I’m just saying my impressions as an end user. Which are fine. But to bring things back on topic, it’s not about whether uv is better or worse than pip or PDM or whatever. The original concern was that if we lose uv\[2\], we’ll have lost something essential. And that simply isn’t true - it’s perfectly possible to incorporate everything uv achieved into existing tools, assuming that (a) we want to, and (b) development resource can be found. 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. * * * 1. arguably pathological 2. Which in itself is a weird comment, we’re not _losing_ uv, although there is a risk that uv now develops in a direction people don’t care for ---
**Author:** ![jamestwebber](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jamestwebber/32/12799_2.png) [@jamestwebber](https://discuss.python.org/u/jamestwebber)\ **Post date:** [March 22, 2026, 5:40pm UTC](https://discuss.python.org/t/openai-to-acquire-astral/106605/41 "2026-03-22T17:40:42Z")
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, @Lucas_Malor [Previous page](https://discuss.python.org/t/openai-to-acquire-astral/106605.md?page=1) [Next page](https://discuss.python.org/t/openai-to-acquire-astral/106605.md?page=3)