4 ms·

> 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

> 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.

BiteCode_dev 4y ago
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. If it was that easy, it would have been done.

BiteCode_dev 4y ago

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. If it was that easy, it would have been done.