i think the main problem was that people didn't believe that pip was broken, or didn't think there was any value in a 100% correct package manager over a 97% correct package manager (e.g. misread "worse is better")
I had the problem basically understood in 2018 and I am still pissed that everybody wanted to keep taking their chances with pip just like they like to gamble with agent coders today.
Now that people know a decent package manager is possible in Python I think there is going to be no problem getting people to maintain one.
Idk how anyone could sustain the impression that pip was not broken unless they had basically never used anything else (including Linux package managers) long enough to have even a basic understanding of it.
And that's a big part of what's so frustrating about Python generally: it seems to be a language used by lots of people who've never used anything else and have an attitude like "why would I ever try anything else"?
Python has a culture where nominal values of user-friendliness, pragmatism, and simplicity often turn into plain old philistinism.
I had a breakthrough moment when someone at a workplace (software dev) said something about a thing that wasn't working on their device. Their language made it clear to me that they didn't know how to troubleshoot to figure out how to fix it. But they could write software that ran on millions of devices. Ok, that made me take a step back.
In the early 2000s I was in a rough patch in my career and wound up working at a small town web design shop that had done a lot of really amazing work, like a line of business system for car dealers, an e-commerce site for vineyards, a custom CRM for an academic department, etc. Nobody there knew about version control (not so weird in 2005) or how to write joins in SQL.
that makes zero sense to me. developing something like ruff from scratch takes a lot of things happening - someone having the idea, the time to develop it from scratch in their free time, or the money to do it as a job, and perhaps the need to find collaborators if it's too large a project for one person. but now ruff is there, there's no need to build it from scratch. if I wanted to build a python linter or formatter I would simply fork ruff and build on top of it. as others have said in this subthread, that's the whole point of open source!
> the time to develop it [not] from scratch in their free time, or the money...
How do you think the magic of open source resolves this issue? Think about this for it to make some sense
> I would simply fork
The only simple part here is pressing the "fork" button, which only gives you exactly the same code that already exists, without user awareness or distribution
you're moving the goalposts now. I never said it would be easy to get used awareness or adoption, just that it would be a lot easier to write a new linter by forking and continuing ruff development than it would doing so from scratch.
as to how the magic of open source resolves the time and money issue, it literally gives you the building blocks you need to not have to invent everything from scratch. how is that not significant?
> just that it would be a lot easier to write a new linter by forking
And I never said about the relative ease, you've moved the goalpost there yourself. $1m required to maintain is much less than $10m required to create, yet when you don't have $1m it doesn't matter - you'll still fail, and reasons are the same as the reasons you couldn't build the original.
Blocks lying around does not a building make, so you haven't addressed that magic either.
it does not take $1M to maintain a linter, these tools can and have been built and maintained by people in their spare time. astral built a better one, for which I am genuinely grateful to them, but it's not like they invented linting or that the open source community was just waiting around for some business to supply their tooling. indeed developer tools are notoriously hard to make money off simply because so many good ones have been developed as either solo or community open source projects, largely by people in their free time.
Cannot we at one point consider the tool to be "done"? I mean, what is there to constantly change and improve? Genuinely curious. It sounds like a tool that can be finished. Can it not be?
