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. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
