I remember doing this pull request over a decade ago:
https://github.com/broadinstitute/xtermcolor/pull/12/files#diff-60f61ab7a8d1910d86d9fda2261620314edcae5894d5aaa236b821c7256badd7
to a project that used setuptools + something to download setuptools
to be able to use it.
I fail to see how that was in any way better than just using what was
in the stdlib.
Setuptools has always been a weird thing to possibly get rid of… and
why have 485 lines of completely unmaintained script to download
setuptools when distutils would do? Well I think the author just
followed some tutorial or guide at that time. But it was problematic
from the beginning that setuptools emerged. And now things are even
worse. Even if my post with the link to xkcd got removed from the
python discuss, the situation remains the same, with new things to do
the same thing being invented all the time.
Il giorno lun 3 giu 2024 alle ore 17:57 Paul Boddie
<p...@boddie.org.uk> ha scritto:
>
> On Monday, 3 June 2024 16:27:29 CEST Donald Stufft wrote:
> >
> > 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.
>
> The way that distutils could not be relied upon to behave in a sensible way is
> entirely the fault of the developer(s) of setuptools having free rein to
> corrupt the Python packaging stack. In environments where I wanted to install
> to a particular location only the software I had already acquired, which is
> largely what the deployment element involved in distribution packaging can be
> reduced to, I did not want to be dealing with setuptools when distutils would
> do, nor with random hacks introduced to make distutils behave like setuptools.
>
> For a while, I routinely stripped out unnecessary setuptools references from
> setup.py files, put distutils support back in, and mostly got the desired
> effect. But in the Python world, once someone teases some fancy new features
> and they catch on, everybody else has to hold on for the wild ride and budget
> for the consequences.
>
> (For some software I have been trying to package, I see now that there is no
> setup.py or anything else, with some more "magic" introduced to be processed
> by yet another tool. I apparently have to get with it, or something to that
> effect, which severely diminishes my interest in packaging that software at
> all. The outcome actually affects the Debian project directly, not that very
> many people seem to care, however.)
>
> I suppose it also didn't help that distutils entered the standard library in
> the era where it was apparently acceptable to get one's code included and to
> then declare the job done. Back when Python 3 was initially introduced, I
> suggested that the standard library be reviewed and fixed up, especially since
> there was going to be a compatibility break anyway, but there was no appetite
> for it.
>
> Still, I appreciate you engaging with this forum, even if it probably means
> having to defend decisions made by others.
>
> 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
