[Python-Dev] BDFL delegation for PEP 426 + distutils freeze

[Éric Araujo]

Hi,

I don’t have a problem with Nick improving the PEP and deciding on its
acceptance.

Le 03/02/2013 07:48, Antoine Pitrou a écrit :
> On Sun, 3 Feb 2013 12:34:36 +0000
> Paul Moore <p.f.moore at gmail.com> wrote:
>> So it's perfectly possible to use wheels right now, without the pip
>> integration. But the pip developers don't want to integrate the wheel
>> format just because it exists - they want the assurance that it's an
>> accepted format supported by PEPs, hence the interest in getting the 3
>> wheel PEPs (of which the metadata PEP is the first) accepted.
> 
> But it's an "accepted format" by whom? If we accept the PEP but refuse
> to integrate support in the stdlib, it doesn't make much sense.
There’s a chicken and egg problem: python-dev could have waited a year
or two to see the wheel format being used and fixed/improved before
deciding to do something in the stdlib, but the pip maintainers wanted
an official blessing first.  Accepting the wheel PEP would mean that
python-dev and the community think wheels are an interesting way
forward, and after some time needed to find out what fixes and
improvements are needed, python-dev is ready to add stable, official
support in the stdlib.

(I know Daniel Holth is frustrated by the wait for what he sees as a
simple format that’s been stable since last year, but it’s really not
long for stdlib inclusion, and there *are* things to sort out.)

> I vote for removing the "distutils is frozen" principle.
I’ve also been thinking about that.  There have been two exceptions to
the freeze, for ABI flags in extension module names and for pycache
directories.  When the stable ABI was added and MvL wanted to change
distutils (I don’t know to do what exactly), Tarek stood firm on the
freeze and asked for any improvement to go into distutils2, and after
MvL said that he would not contibute to an outside project, we merged d2
into the stdlib.  Namespace packages did not impact distutils either.
Now that we’ve removed packaging from the stdlib, we have two Python
features that are not supported in the standard packaging system, and I
agree that it is a bad thing for our users.

I’d like to propose a reformulation of the freeze:
- refactorings for the sake of cleanup are still shunned
- fixes to really old bugs that have become the expected behavior are
  still avoided
- fixes to follow OS changes are still allowed (we’ve had a number for
  Debian multiarch, Apple moving stuff around, Windows manifest options
  changes)
- support for Python evolutions that involve totally new code, commands
  or setup parameters are now possible (this enables stable API support
  as well as a new bdist format)
- behavior changes to track Python behavior changes are now possible
  (this enables recognizing namespace packages, unless we decide they
  need a new setup parameter)

We’ll probably need to talk this over at PyCon (FYI I won’t be at the
language summit but I’ll take part in the packaging mini-summit planned
thanks to Nick).

Regards