I did think that updating distutils to have basic support for the packaging PEPs was a decent idea, but then it wound up being more or less rewritten entirely like I've been cajoled into doing with PEP 426 (Metadata). I don't know whether distutils(1) can survive the minimum changes required for wheel (.dist-info folders and a bdist_wheel command) without breaking a significant number of its clients or not. History suggests no. It may still be worth a shot.

bdist_wheel started out as a distutils2 plugin but it was inconvenient to develop it inside the CPython repository and it was not practical to convert projects over from setuptools to distutils2.

The pypi metadata has had a standardlib generator for a long time without having anything in the standard library to make use of the metadata. Wheels are just .zip files of one package's share of the site-packages directory. Why not support them asymmetrically. I value the PEP and consensus for the format more than the implementation.

One idea that's sure to be controversial would be to include a bootstrap installer as a script without committing to a Python API (just a command-line API). Since Python 2.6, wheel's own wheel archive can be used to install wheels:
$ python wheel-0.14.0-py2.py3-none-any.whl/wheel -h
usage: wheel [-h] {keygen,sign,verify,unpack,install,convert,help} ...


On Sun, Feb 3, 2013 at 2:40 PM, Chris Jerdonek <chris.jerdonek@gmail.com> wrote:
On Sun, Feb 3, 2013 at 10:33 AM, Éric Araujo <merwok@netwok.org> wrote:
> Le 03/02/2013 07:48, Antoine Pitrou a écrit :
>> 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:

This could be common knowledge, but is the current formulation of the
freeze spelled out somewhere?

--Chris