On Fri, Sep 04, 2020 at 01:10:37PM -0400, Paul Ganssle wrote: > On 9/4/20 12:45 PM, Stefan Krah wrote: > > Since distutils does not change, why remove it? It is a lot of work > > for people with little gain. > > If we don't remove it, we should at least freeze the bug component so > that people cannot report bugs in distutils. Triaging these bugs alone > is a decent amount of work. We should probably also set up a Bedevere to > auto-reject PRs that touch distutils files (since telling people that > distutils is frozen and no longer maintained is effort as well), and > disable distutils in the CI so that it does not generate work for people > maintaining the buildbots.
That is fine, but also note that Victor reported a CI issue introduced by the external setuptools package. > > I'd really like to build C extensions without downloading an external > > package. > How often do you actually build extensions without building or > installing external packages? All the time, especially when I'm writing them. I imagine that there's a huge amount of internal company code that discourages use of pip installed packages as well. Or has an air-gapped network in the first place. > > Features like C++ support have not been worked on for more than a > > decade. Are the setuptools maintainers planning to address these > > issues now? > > > Considering that we /aren't/ adding anything to distutils today, the > chances of this happening in setuptools are pretty much strictly better > than in distutils. Given the time constraints that everyone (rightfully!) has, I'd say the chances are rather low. My point was that features should not be a reason for deprecating distutils. Stefan Krah _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6NSEX5DXKUT2W5O5OPKCAQUOPCIDGQBA/ Code of Conduct: http://python.org/psf/codeofconduct/