OpenAI to acquire Astral

Accelerates Codex growth to power the next generation of Python developer tools

Admittedly, most of what I use `uv` for now is to install PDM, as the uv installation script is much more reliable than PDM's. If PDM had an equivalent to `uv tool install`, I could leave `uv` without looking back.

Replacing `ruff` is harder, and replacing `ty` is almost impossible.

The main reason I was fine using uv was that it did a very good job of following the PEPs when they existed, and giving clear, transparent reasons for not doing so when they made exceptions (like why they didn't adopt pylock.toml).

Other than PDM, though, there's just so little in the way of Python package management tooling that does a good job of bootstrapping and for declaratively managing venvs.

I've said it before, but I'm not happy having `python` on PATH. That's an easy way to have global system state leak into project dependencies. Not having `python` on PATH let me discover where a chain of different build tools escaped the venv and picked up system-wide site-packages.

uv got that right, imho.

God *damn* I'm depressed right now.

(Yes, I know about pipx. It assumes that the Python it was run with is the same Python it should use for all the applications it installs, and that's not what I'm looking for.)
Exploring Nix Shell, A Game-Changer for Ephemeral Environments

Original Post

Medium

@xgranade I'm pretty happy with pipx. It also does allow you to specify which Python each application should use:

$ pipx install --help
usage: pipx install [-h] [--quiet] [--verbose] [--global] [--include-deps]
[--force] [--suffix SUFFIX] [--python PYTHON]
[--fetch-missing-python] [--preinstall PREINSTALL]
[--system-site-packages] [--index-url INDEX_URL]
[--editable] [--pip-args PIP_ARGS]
package_spec [package_spec ...]

[...]

--python PYTHON Python to install with. Possible values can be the
executable name (python3.11), the version of an
available system Python or to pass to py launcher
(3.11), or the full path to the executable. Requires
Python 3.9 or above.
--fetch-missing-python
Whether to fetch a standalone python build from
GitHub if the specified python version is not found
locally on the system.

I have a mix of stuff installed with Python 3.11, 3.12, and 3.13 using it.

uv tool install is great too, but there is one edge case bug for my use case I keep running into with it. So I've stuck with pipx.

@xgranade python -m pipx ?
@whitequark Yeah, gonna have to do something like that. I just... `uv tool install` had exactly the semantics I was looking for, I really wish PDM had that feature.
@xgranade you’re right, but I disagree :(
@xgranade isolation is powerful, it’s just very inconvenient for me, a power user,
@kouhai I mean, I'm also a power user, but yeah... I definitely understand. Being able to pierce layers of abstraction is always good, even when those layers are also good?
@kouhai @xgranade personally, I prefer not to have python on my PATH, but as a gentoo user I'm not allowed not to :'(

@demize @xgranade :c rude

what did python do to you

@kouhai @demize Many, many, *many* things. Some of them are good, hell a lot of them are good. Not all of them.

@kouhai @xgranade hey, I like python

as long as it’s shoved into the nice neat little boxes each called “.venv”

@demize @xgranade I can’t fault you for that, but I would like a user level Python dependency closure… T_T
@kouhai @xgranade valid! just not something I need, with how I use my computer :p
@demize @kouhai This is the way.

@xgranade @demize this is what I do for server things!

but, I want my user-site-packages…

@kouhai @demize Fair, I've hit so many edge cases with having a single user-facing environment, I don't trust *myself* without managed venvs.
@xgranade @kouhai 💭 what if the user site and system site were just venvs that you can use from anywhere
@demize @xgranade this would be ideal tbh
@demize @xgranade I know how to implement it, even!

@kouhai @xgranade it’s definitely not a unique or original idea, but I can’t remember if I’ve seen anything actually do it (or what it would have been)

but I’d like to see something do it!

@xgranade WELP back to pyenv/venvs
@qualia @xgranade This is why I like my Python project tooling as boring as possible, I never stopped using venv and setuptools.

@j0057 @qualia That's why I'm so sad about this, uv was the single most boring Python tool I have ever seen, with the possible exception of PDM.

setuptools has provided me with many amusing sidequests over the years, I'll just say.

@xgranade I think you mean "forking"

as in, what we should all do on those projects immediately

@joshg Forking is just way too difficult without a funding model for how to maintain those forks. This is a serious blow.

@xgranade imagine if there was some kind of incentive to say 'no' to this kind of buyout.

Imagine if monopoly-chasing hyper scale companies weren't allowed to roll over in their sleep and murder common-good projects with offers too good to refuse.

Imagine if people cared.

@jacel @xgranade I'm thinking there should be a world-wide law that says all code repositories must have a --no-ai-up-to-here-- tag in them. In most cases this would hopefully be at the head, but in others it will at least show the last uncorrupted check-in from which new branches should be taken.
@xgranade the speed at which this latest round of AI capital is setting fire to the python ecosystem is frankly shocking

@xgranade best case scenario is they end up leaving the tools alone (I suppose the real best case is they keep getting improved but I won't hold my breath). Worst case scenario is uv will send the requirements to chatgpt for resolution and also upload the files for ruff to use chatgpt for formatting. /s

I just don't see the point of this purchase outside of the talent and letting the original tools languish. I guess that's what I'd hope for anyway.

@xgranade *strikes learning uv off the TODO*