It's not an accurate characterization that distutils was removed simply because it wasn't maintained.
It was as fragile library, and it was difficult to make any changes to it because a number of things had implemented themselves by reaching into distutils and randomly monkeypatching various aspects. This made it hard to maintain it _at all_, because when people had tried to improve it, it caused ecosystem wide breakages until things like setuptools, numpy.distutils, etc got patched again. So the unofficial policy became "do not touch distutils", for fear of causing these breakages. In the interim the packaging toolchain evolved to the point that having distutils in the stdlib was no longer of general benefit, and in fact made things worse because people had grown accustomed to things like `from distutils import setup` being transparently monkeypatched to be setuptools under the covers. Ultimately, distutils had diverged so far from modern packaging tooling (due to the unofficial policy of not touching it), that it's existence was more or less a footgun, and it's only real purpose anymore was to be an implementation detail of other libraries, which you had to install from PyPI, so it was decided it was better to remove it rather than leave it around. On 6/3/2024 1:37:32 AM, Salvo Tomaselli <tipos...@tiscali.it> wrote: Consider that they are the same people that recently removed "distutils" from the standard library, because it was not maintained. When they have well enough funding to assign someone to maintain it, instead of relying on external projects to install packages. I think they are in the bubble of "people who are here on discuss" and forgot the 99.9% who is not. Il giorno lun 3 giu 2024 alle ore 00:08 Paul Boddie ha scritto: > > On Monday, 27 May 2024 04:07:34 CEST Scott Kitterman wrote: > > > > While there are technical concerns on both sides, socially I think the > > Python community isn't that interested in outside perspectives. > > I managed to dig up these notes from the packaging summit at PyCon: > > https://hackmd.io/@pradyunsg/pycon2024-pack-summit > > Here's the summit page itself: > > https://us.pycon.org/2024/events/packaging-summit/ > > There is some fixation on the "system Python" in distributions, and the > following remarks: > > "At least one distro team is working on moving their own Python out of the > way, so users can install their own Python packages [...] Fedora tried > platform-python and it broke everything, so it didn't really work" > > Given the proliferation of "virtual environments" around Python, where you > just pick your own Python version and accompanying packages, I find it odd > that the Python packaging community gets so hung up on the system Python. Do > they want it to just go away or not be on the path or something? Wouldn't > having a singular upstream Python just cause the same problems when someone > finds that it isn't the version they need? > > For my own amusement and to confirm my own memories, I went back in time to > check the Python Web site in the 1990s, and back then there was no problem in > providing a binary for Linux and the Unix products of choice from that era. > AIX, FreeBSD, HP-UX, Irix, OSF/1, Solaris, and SunOS 4, plus a Linux binary > supplied either as an RPM or in a plain archive: > > https://web.archive.org/web/20021030010019/http://www.python.org/ftp/python/ > binaries-1.4/ > > What is stopping anyone from doing that all over again? The user downloads the > binary, puts it in their current directory, and runs their software. Could it > be that the burden of support is perhaps a little greater than one might > expect? > > Because from that starting point, you have to build multiple versions, and > then you have to build accompanying libraries, and then you have to support > third-party packages which need third-party libraries. It wasn't a surprise > that things like Sun Freeware (http://www.sunfreeware.com) emerged to cater to > the proprietary platforms, whereas distributions emerged around Linux to > manage this complexity and provide all this software. > > It is easy for the various language communities to focus only on their own > ecosystems, but everybody's software has to work together. And then there are > companies targeting various markets that demand software built on a selection > of different technologies, so you get perspectives like these: > > "Why did the PyPI and Conda ecosystem get created? It was originally created > as an educational teaching language. If all of your tools are in Python, all > of the things in your ecosystem are supposed to work well together. However, > the tools that scientists and data scientists use are very commonly written in > C, C++, etc. and so there’s something called a “native binary problem”. Making > this stuff compatible across the board is an incredibly challenging issue! > Conda was created to resolve those binary compatibility issues." > > I honestly don't know what these people think operating system distributions > are doing if not solving the "native binary problem". > > Paul > > -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io [937b435c-411d-4ec4-8588-691dce8610f2]
