On Sun, Jul 1, 2012 at 1:52 AM, Daniel Holth <dholth@gmail.com> wrote:
I got tired of waiting for lxml to compile over and over again, so I
invented a binary packaging format called 'wheel' (of cheese) that
uses Metadata 1.2 and .dist-info directories instead of .egg-info,
patched pkg_resources.py to be able to load .dist-info directories,
implemented "python setup.py bdist_wheel", and patched pip to be able
to install .whl files.

The gist of the spec is that it is a zip file with the .whl extension
containing the contents of 'purelib' for a distribution, plus a
Name-1.0.dist-info/ directory with the metadata files, plus
Name-1.0.data/subdir directories for scripts, platlib, packaging's
"categories", ...

My specification so far is at
https://docs.google.com/document/d/1mWPyvoeiqCrAy4UPNnvaz7Cgrqm4s_cfaTauAeJWABI/edit
and an lxml compiled for linux-x86-64 is at
https://docs.google.com/open?id=0BxHz5bC4iN5TN0VWTFNrZGtCbWs

http://bitbucket.org/dholth/distribute
http://github.com/dholth/pip
http://pypi.python.org/pypi/wheel

Perhaps it will be useful. The implementation is still pretty rough,
for example it does not check the architecture while installing, but
it could be a handy way to speed up repeated virtualenv builds.


While I haven't studied the spec in detail yet, I just want to say "hurray!" for somebody Just Doing Something About It.  From a feature perspective, the only thing missing (IMO) would be the ability for pip to consume .egg and win32.exe's in order to provide a migration path.  Win32.exe->egg conversion code exists in easy_install, and converting eggs to wheels should be straightforward  as well, despite the mixed metaphor.  ;-)

Btw, looking at the packaging docs cited in the spec, I'm confused about something: it's not clear to me what resource category most data files would be placed in, if they are actually application code.  For example, a ZCML spec file is not editable and would thus not properly go into "config".  ZPT files (or for that matter, most other HTML templating language files) aren't data in any meaningful sense, either.  So what *is* the correct category for such *code* files which are part of the library or application, yet which are not Python modules?  The doc provides no guidance on this point.