[Distutils] Comments on PEP 426

[Donald Stufft]

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.

Replacing distutils whole hog with something else is the wrong
approach. It's the exact same problem we've had all along just with
somewhat better symptoms.

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

Lesser of two evils.

> 
>> *Hopefully* a dominant 80% simpler-use-cases distutils replacement
>> will emerge along
> 
> "Hopefully"? "Emerge" magically? Software doesn't grow on trees…

Of course not, but that's not exactly what the statement says. Different
people will create different tooling and ideally there will begin to be
community consensus behind one of them.

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

A lot of the problems of the packaging eco system descend from ``import distutils``
and then ``import setuptools`` making it near impossible to actually replace
one or the other without gross hacks. Setuptools at least provides some mechanism
for extension and actually solves a lot of problems with distutils.

-----------------
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/806d4f49/attachment.sig>