[Distutils] Comments on PEP 426
solipsis at pitrou.net
Sat Aug 31 12:30:23 CEST 2013
Daniel Holth <dholth <at> gmail.com> writes:
> One of the most important packaging insights to understand is that
> distutils is in fact worse than setuptools. It is badly outdated,
> poorly extensible, and too complex to ever re-implement in a
> compatible way. It is not better before the monkey patching. In a
> perfect world it should be removed from the standard library too
> except that removing distutils would be too impractical.
Well, in a perfect world it would have a replacement. It would not
just "be removed" and replaced with a black hole.
> The new strategy is to standardize just the install (how to install a
> wheel binary package after it has already been built) and runtime for
> eventual standard library inclusion. These are simple enough that they
> can be documented and re-implemented adequately. Distutils and
> setuptools will both be equally discouraged as legacy build tools.
If setuptools is "discouraged", why "bless it officially"?
That doesn't make sense.
> *Hopefully* a dominant 80% simpler-use-cases distutils replacement
> will emerge along
"Hopefully"? "Emerge" magically? Software doesn't grow on trees...
> with a more complicated 20% "scipy" distutils
> replacement but neither will necessarily need to be in the standard
If users start to have to install third-party software to build and
package their own libraries, then it's a huge regression (regardless
of what *you* may think about "batteries included").
> If you can believe that distutils, not setuptools, is the problem we
> are trying to recover from, then the monkeypatching strategy may make
> more sense.
I do *not* believe there is a single "problem" we are trying to "recover
from". This is IMHO a crude way of pointing fingers, while the truth
is that no popular replacement has yet "emerged" despite at least 10 years
More information about the Distutils-SIG