On Sat, Sep 3, 2016 at 5:06 PM, Nick Coghlan
On 2 September 2016 at 19:28, Paul Moore
wrote: On 2 September 2016 at 09:58, Sylvain Corlay
wrote: My point here was that I don't think that the proposed feature has much to do with the concerns that were raised about distutils in general, unless it is decided that incremental improvements to the library even backward compatible will not be accepted anymore.
Agreed. I think your feature is only stalled for distutils by the lack of people sufficiently comfortable with the code to apply it. The suggestions to add it to setuptools are more in the way of practical advice on how to make the feature available, rather than expressions of a policy that "we don't make changes like that in the stdlib".
However, one of the other consequences of the status quo is that if Jason's comfortable with a change for setuptools, there's very rarely going to be anyone that will argue with him if he also considers it a suitable addition to the next version of distutils :)
Since Jason's primary involvement in distutils-sig & PyPA is as the lead setuptools maintainer, it's easy for folks to be unaware of the fact that he's a distutils maintainer as well.
So perhaps that's what we should adopt as the official distutils-sig policy? Any proposed distutils changes should *always* go into setuptools, as that way they're available for all currently supported Python versions,
and better maintained, and easier to fix if there's bugs, etc.
and then it's up to the setuptools project to escalate changes or change proposals for stdlib inclusion when they consider that an appropriate step.
+1. clear and pragmatic policy. Ralf