> This doesn't include the dozens of third party projects that target improving package that came out in the last 2 decades.
One would think that two decades of package improvement initiatives should have been a strong enough signal to PSF to prioritize building an official standard solution.
A third party can ignore legacy. It can break stuff. It can avoid supporting platform. It can have a big bug and push a fix the day later. It can skip red tapes. It can document after the fact. It can drop features the next year. It can requires pypi dependancies when the stdlib is not sufficient. It can be by a single author that don't have to ask anybody what they think about before creating something. It can skip security issues and focus on practicality.
CPython cannot.
So any change to the packaging story will always take years for the smalles thing.
That's the same for removing the GIL: touching the c api is a huge deal for the scientific and machine learning stack.
That's why requests has never been included in python despite being vendored with pip: you can never update it fast enough once it's in the stdlib.
That's why we don't have node_modules equivalent yet: autoloading code in the current directory would be a big security risk for a language that is included in many os by default so we need a good design.
Don't assume the team is incompetent or deaf. Given what has already been achieved, that would be a total mismatch.
> Don't assume the team is incompetent or deaf. Given what has already been achieved, that would be a total mismatch.
I am not making any such assumptions (and I don't think most sane people are either); people are just unhappy with lack of an officially standard solution given that it was clear quite a while ago that it was needed. I also don't understand the comparison with GIL or C API - changes to them could be a breaking change whereas a fresh officially recommended solution would by definition be a new solution i.e. not a breaking change. It can be introduced and it can go through iterations while people can take their time to migrate from the myriad of third-party packages (or not, if they are happy with what they are using).
What people, who don't want to deal with deciding between or putting their faith in longevity of third-party tools, are looking for is a solution that is official, part of the standard library and is managed by PSF. That way the decision is basically made for them e.g. like it is done in Rust via cargo.
Fresh now solutions is what put us in this situation: distutis2 was fresh, setuptools was fresh, pip was fresh, wheels were fresh... So now you have a lot of complexity that come from having a lot of solutions in parallel that are slow to sunset.
But the dirty secret of python packaging is that most of the problem don't come from packaging, but from boostrapping python. And this is a huge can of worms I didn't even mentioned.
Also, plenty of things require the participations of other communities like debian splitting pip out of the main package or anaconda not being compatible with pip.
All in all, the way you hand wave the problem is typical from the critics that have a very narrow view of the situation.
>Don't assume the team is incompetent or deaf. Given what has already been achieved, that would be a total mismatch
To be perfectly clear, I don't think that. I just think its a missed opportunity over the years to better ways of environment and package management. For instance, on the folder auto loading code: make it a feature of only virtual environments. I know python can detect that its in one. Or engage with distros not to build Python to allow this. They already do custom builds with it (its always missing something from a standard Python installation after all).
Node also has madness that Python does not, like support for circular dependencies. I would definitely not point to Node as a positive example like Cargo.
Cargo is the golden standard, but reaching that level is going to take 10 years at least. I'm not kidding, this is what will be needed to solve all the road blocks.
The first thing we need is a whole ne way of installing python, because half of the problems stems from that. That's just a huge endeavor.
One would think that two decades of package improvement initiatives should have been a strong enough signal to PSF to prioritize building an official standard solution.