[Distutils] Comments on PEP 426

Antoine Pitrou 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
> library;

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

Regards

Antoine.




More information about the Distutils-SIG mailing list