<div dir="ltr"><div>Distutils seems to be the de-facto standard for building extension modules for Python and it is used for most of the third-party extensions out there. I don’t think that it is reasonable to declare that it is now only meant for Python itself. I actually see a contradiction in pointing out some lack of involvement in the library to oppose well needed improvements, especially for a tool that has so much adoption.</div><div><br></div><div>As we discussed earlier, even though it is not a concern with C, checking for availability of a compiler flag becomes crucial when building extensions with C++ since new flavors of the language emerge every couple of years now. It is important to be able to output meaningful error messages when the compiler does not support C++[11/14/17] features if they are needed for a given extension. This is a new aspect of the landscape in this area.</div><div><br></div><div>Finally, adding this method is a very straightforward change. `has_flag` simply comes aside `has_function` as a method of ccompiler. I don't see a more natural place for it. It would be a very weird design decision in my opinion to not add it there, and instead to add it to distutils.ccompiler by monkeypatching it in setuptools.</div><div><br></div><div>Thanks,</div><div><br></div><div>Sylvain</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 29, 2016 at 12:36 AM, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 28 August 2016 at 18:05, Brett Cannon <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br>
> The discussion of Sylvain's proposed changes to distutils suggests that<br>
> there isn't a clear-cut agreement or position of this SIG -- and thus Python<br>
> -- on changes to distutils, its future, etc. Is there an official position<br>
> I'm not aware of? If not, could we get one so we know how to handle any more<br>
> proposed changes to distutils?<br>
><br>
> For me personally (and to start this conversation if necessary), I view<br>
> distutils as the package in the stdlib that handles building extension<br>
> modules in the stdlib for Python. That view means that if something doesn't<br>
> service that explicit goal then it shouldn't go into distutils. Now that we<br>
> are moving down the road towards making the build step configurable I'm fine<br>
> with saying that distutils is not expected to work for people other than<br>
> Python itself and others can use setuptools, enscons, or other projects<br>
> while we continue to improve the situation to where the build system is just<br>
> something you specify in pyproject.toml to generate your wheel. IOW<br>
> distutils is only exposed publicly because Python doesn't hide anything, but<br>
> making it useful for the general case of direct usage by people is a<br>
> non-goal of the package.<br>
<br>
</div></div>FWIW, my view is:<br>
<br>
* distutils handles building of Python packages, both in the stdlib and outside<br>
* in practice, setuptools is almost always used with distutils, and<br>
any proposed change to distutils could be made to setuptools just as<br>
easily<br>
* patches for distutils typically suffer from a lack of maintainers<br>
motivated to work on them<br>
* there are a few developers with a strong investment in distutils,<br>
who have code that is deeply entwined with the internals of distutils,<br>
and changes to distutils come with a high risk of causing issues for<br>
those people<br>
* these developers *don't* use setuptools, so changes in setuptools<br>
don't tend to suffer from the same level of backward compatibility<br>
constraints<br>
* implementing changes in setuptools is *far* easier than doing so in<br>
distutils, for the above reasons<br>
* changes in setuptools can be used with any version of Python,<br>
distutils changes are only available to people with no need to support<br>
anything but the latest version (which in practice is a vanishingly<br>
small group)<br>
* as a result, there would have to be an *extremely* compelling reason<br>
to make a change in distutils rather than in setuptools - sufficient<br>
to justify the additional risk, the extra developer effort needed, and<br>
the fact that any such change is only going to benefit users of newer<br>
versions of Python<br>
<br>
The reality is simply that distutils is in a somewhat unhappy place,<br>
with too few interested maintainers and serious compatibility problems<br>
to deal with, but that's not exactly news to anyone. I don't think<br>
that a formal statement will help much. Past history has shown that<br>
making pronouncements like "distutils is frozen" has not helped anyone<br>
- so we're just trying to work with the status quo.<br>
<br>
With regard to Sylvain's proposed changes, I haven't really seen any<br>
arguments justifying making the change in distutils rather than in<br>
setuptools - the last suggestion I saw was to make the change in<br>
*both* places, but I don't see any particular reason (beyond abstract<br>
"it makes more sense to have the change in distutils" arguments) for<br>
not just targeting setuptools. I may be missing something (as I'm not<br>
personally in a position where I'd be comfortable reviewing the<br>
change) but it seems to me that it's a bit of a non-issue - just<br>
implement in setuptools and move on. The rhetoric about "this means<br>
that distutils is dead" doesn't feel particularly helpful.<br>
<span class="HOEnZb"><font color="#888888"><br>
Paul<br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/distutils-sig</a><br>
</div></div></blockquote></div><br></div>