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

On Sun, 3 Feb 2013 12:34:36 +0000 Paul Moore 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

I vote for removing the "distutils is frozen" principle. I’ve also been thinking about that. There have been two exceptions to

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 : 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.) 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