![](https://secure.gravatar.com/avatar/d7ff36e4d7c8060fadaa7c20f4a5649e.jpg?s=120&d=mm&r=g)
Looks like your biggest Py3 issue is that distribute uses 2to3. "pip install -e" of course does not. It works much better otherwise. I put in some tiny changes to the other bits to make them work, and I can now install Pyramid from wheels on Py3.2. On Mon, Jul 2, 2012 at 11:59 AM, Paul Moore <p.f.moore@gmail.com> wrote:
Hmm, I'm a little confused as to how the bits hang together here. Maybe some clarification would help. How close is the following?
pip - your patch for this is to recognise wheel files and use distribute to install them distribute - your patch for this is to add support for installing wheel files (and to add a bdist_wheel command for building them???) wheel - support library for the above, provides functions to work with wheel files
Is that close?
Assuming it is, I'm not sure I follow what you say in the paragraph above - what is the cpython patch you mention?
No longer important, just the first thing I tried. It is a bdist_wheel for distutils2 / packaging. It wound up being much more fun to write a setuptools/distribute plugin, so I finished there. The most important and most complete patch is probably pkg_resources.py (part of setuptools / distribute) to recognize the .dist-info directories and the Provides-Extra: extension. This is just PEP 386 and is not wheel specific. If 'markerlib' is installed it will interpret conditional requirements; markerlib should become standard/required. The distribution 'wheel' is the bdist_wheel setuptools plugin. It is also where a command line tool to manipulate wheel files would go. pip recognizes wheels and installs them itself. https://github.com/dholth/pip/blob/develop/pip/req.py#L759 It doesn't yet +x scripts or update .dist-info/RECORD to keep track of what it should uninstall.
Based on my interpretation of what you say above, the things I see outstanding are:
1. wheel discovery and download from PyPI or local archives (so pip install x will find and download x.whl before/as well as an x sdist) 2. wheel upload to PyPI (probably needs PyPI changes to support the new format)
Also, we will be moving to urlsafe-b64encoded SHA256 instead of MD5 as the hash function.
3. converters to allow people to convert eggs and bdist_wininst binaries to wheel format (otherwise you have a chicken-and-egg problem in that wheels are only good for speeding up installs, rather than for installing things you can't build for yourself)
Sure, although IMO egg2wheel is more of a roundabout way to get around the "pip doesn't support eggs" issue. Hopefully in most cases the maintainer or "someone with a compiler" will run bdist_wheel for you when a new version comes out.
(1) and (2) are longer-term requirements, and (3) may or may not be a key requirement for you - in any case, others who do need the facility could develop these independently. So it seems to me like you're nearly there (assuming the pip and distribute maintainers accept your patches).
Paul.