On Fri, 2 Sep 2016 at 22:06 Nick Coghlan <ncogh...@gmail.com> wrote: > On 2 September 2016 at 19:28, Paul Moore <p.f.mo...@gmail.com> wrote: > > On 2 September 2016 at 09:58, Sylvain Corlay <sylvain.cor...@gmail.com> > 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 then it's up to the setuptools project to > escalate changes or change proposals for stdlib inclusion when they > consider that an appropriate step. >
If Jason is up for the responsibility that seems like a reasonable approach to take. It also helps test out features in setuptools first before upstreaming it.
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
