Remember, people. When a tool is:
⁃ open source
⁃ built to conform to open specifications
⁃ not coupled to a service offering

It does not matter who buys the company that built the tool

@offby1 My concern is more that the suite of projects in question only had such a high level of velocity, maintained-ness and polish because people were literally being paid, as their job, to do it. Once the money dries up, even the best-case outcomes still probably involve huge drop-offs in all those attributes due to the switch from "this is my job" to "this is my side/hobby project".
@ubernostrum Totally valid in terms of what future development will look like, but only barely relevant in terms of what's already there... and what's already there is a phenomenal upgrade to the python packaging experience.
@offby1 I feel like a lot of the credit given to uv actually belongs to the broader Python packaging community for working out the necessary standards to actually improve things; uv just was able to rapidly adopt and implement because it was literally someone's job (several someones) to do so. Compare to pip, where I know from personal experience that it's a struggle to get implementation of crucial new standards because it's a side project that has to fight for time even when funding is on offer.

@ubernostrum I agree with that formulation.

Again, the reaction I'm pushing back on is the one where people are (and I am not exaggerating here) saying python packaging is doomed now.

That's just not reasonable or realistic.

It's unlikely to improve as fast and consistently, but it is not doomed, and I wish that people would not react as though this was undoing what they've done that was good.

@ubernostrum @offby1 If you want to see when the major workflow tools added support for something, I have it documented at https://opensource.snarky.ca/Python/Workflow/Launcher/Plans#Subcommands ; look at each page in that directory and it most have a table listing when a tool added support.

Spoiler alert: uv was not first in any case except `pylock.toml` support that I'm aware of. What uv did do is get the features in front of more people due to its popularity.

Plans - Open Source by Brett Cannon

To run Python code you need to ... 1. Choose the appropriate/best language version Find/install an interpreter to meet that language version need (`py install`) Create a virtual environment that uses…

Open Source by Brett Cannon

@brettcannon @offby1 To be clear I'm not saying uv was first to have things, just that I think the fact that it was literally people's day job to work on it meant they had a high average velocity that volunteer projects can't easily match.

For example, even when I had a line on potential funding for pylock.toml install support in pip, I was told it would still come down to whether a pip maintainer could find the time to supervise and review.

@ubernostrum @offby1 I was posting to support you in saying uv didn't pioneer a lot of the things they are given credit for (heck, I wrote the Python Launcher in Unix in Rust ages ago, so I used Rust for Python tooling before they did πŸ˜‰).