[Python-Dev] Moderating the severity of the distutils freeze

[Nick Coghlan]

On Thu, Feb 7, 2013 at 6:45 AM, Éric Araujo <merwok at netwok.org> wrote:
> Bug fixes are possible; changes to keep working with Python (i.e. pyc
> files are generated in pycache directories after 3.2); changes to be
> able to build on current OSes (e.g. following Mac dev tools location
> change, introduction of Debian multiarch, etc.).
>
> Some bugs have been here for so long that everybody depends on them or
> work around them, or they would be extremely painful to fix (e.g. in the
> option parsing code) for little benefit, so they are wontfix.
>
> Cleanups, refactorings and improvements were banned by the feature freeze.

I think the points to be clarified are that *new* internal APIs
(including new commands, like bdist_wheel) are legitimate in a feature
release, and internal changes which don't affect APIs (like some of
the tweaks Dave Malcolm and I made to try to make building Python 3
RPMs on RHEL 6 with bdist_rpm less broken) are legitimate in
maintenance releases.

distutils is going to be around for a long time for backwards
compatibility reasons, so if people want to improve it within those
constraints they should be allowed to - we just need to be extra
careful with maintenance releases, by treating even nominally internal
APIs as if they were public. The current interpretation of the
situation as a complete "no few features" freeze is overkill, when the
setuptools/distribute developers will have plenty of time to send up
warning flares during the alpha/beta/rc cycle. An appropriate rule
would be more like "no major refactorings of distutils internals"
(which may indeed mean distutils never supports metadata versions past
1.1).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia