[Distutils] Proposed new Distutils API for compiler flag detection (Issue26689)

[tritium-list at sdamon.com]

Changing packaging by updating the standard library will fail.  It’s been attempted.

 

The inherent problem is you need to fix packaging for people already using python, which means if you add a feature to the standard library, only the people who always run the latest and greatest can ever use the feature.  In a world where we are talking about Python 3.6/3.7 and python 2.7 is by far the most used version of python (and python usage is split pretty evenly between 3.4 and 3.5 IIRC), no one will use new packaging features in the standard library.

 

Putting something in setuptools means it will actually be used.  I think some of the goals of this sig is to be able to completely sunset distutils and replace it with much better solutions (plural) that all speak the same protocol.

 

From: Distutils-SIG [mailto:distutils-sig-bounces+tritium-list=sdamon.com at python.org] On Behalf Of Sylvain Corlay
Sent: Monday, August 22, 2016 2:16 AM
To: Ralf Gommers <ralf.gommers at gmail.com>
Cc: distutils-sig <distutils-sig at python.org>
Subject: Re: [Distutils] Proposed new Distutils API for compiler flag detection (Issue26689)

 

Hi,

On Sun, Aug 21, 2016 at 10:31 PM, Ralf Gommers <ralf.gommers at gmail.com <mailto:ralf.gommers at gmail.com> > wrote:


On top of that there are technical reasons (don't want to test combinations of python + setuptools that both change per release) and organizational ones (distutils maintenance is terrible, many simple bugfix patches don't get merged for ages, setuptools at least fixes regressions quite fast).

 

I'm not sure if there's an official policy on adding new things to distutils, but if not then this request is a good time to make one. Assuming of course that the setuptools devs are willing to merge features like the one from Sylvain.

 

 

I find this worrying that the main arguments to not include a patch would be that

 

 - this part of the standard library is not very maintained (things don't get merged)

 - earlier versions of won't have it

 

The former is a bad sign for a standard library and the latter is inherent to any new feature. Whether it is a policy or not to not add new features to distutils it is clear that a code base that does not evolve is dead.

 

How about, instead, we continue improving it?

 

Sylvain

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160822/83542d7b/attachment.html>