[Distutils] Comments on PEP 426

Donald Stufft donald at stufft.io
Sat Aug 31 12:34:07 CEST 2013

On Aug 31, 2013, at 6:30 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:

> 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").

I haven't followed this thread yet, but just to comment on this users are
already installing third party software to build and package their own
libraries. From what i've seen working with packaging distutils is either
a fallback or not used at all in the bulk of cases.

>> 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 at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig

Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130831/73b6337f/attachment.sig>

More information about the Distutils-SIG mailing list