<html><head></head><body bgcolor="#FFFFFF"><div>Thanks.</div><div><br></div><div>Most of "wheel" is just implementing the specs we have, like metadata 1.2 and a lot of tarek et al work on packaging. The point of the implementation is that we can immediately benefit from a documented install format without having to convert everyone over to the same build system. The build and install phases can be decoupled as they should be.</div><div><br></div><div>The resource categories in .data come from the distutils2/packaging setup.cfg specification. They are mostly for including man pages, include files and so forth. If it doesn't go directly in site packages, it goes there. The wheel spec doesn't know what they are for, it only tells you where to archive them.</div><div><br></div><div>I'm convinced that data that the code really needs at runtime should continue to go right next to the .py files as usual. Time will tell as to the utility of .data. I think .data will make Debian maintainers happy.</div><div><br></div><div>The new setup command bdist_wheel does exactly the task of converting egg-info to dist-info. It just doesn't understand prebuilt eggs.</div><div><br></div><div>The tripartite compatibility tag python version - abi - architecture is what I need the most advice with. I want to anticipate a multi implementation world where the abi is not tied to the version of the python language used, and I want to be able to put several architectures of shared libraries in the same .whl when those shared libraries have unique file names.</div><div><br>Daniel Holth</div><div><br>On Jul 1, 2012, at 2:00 PM, PJ Eby <<a href="mailto:pje@telecommunity.com">pje@telecommunity.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><div class="gmail_quote">On Sun, Jul 1, 2012 at 1:52 AM, Daniel Holth <span dir="ltr"><<a href="mailto:dholth@gmail.com" target="_blank">dholth@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I got tired of waiting for lxml to compile over and over again, so I<br>
invented a binary packaging format called 'wheel' (of cheese) that<br>
uses Metadata 1.2 and .dist-info directories instead of .egg-info,<br>
patched pkg_resources.py to be able to load .dist-info directories,<br>
implemented "python setup.py bdist_wheel", and patched pip to be able<br>
to install .whl files.<br>
<br>
The gist of the spec is that it is a zip file with the .whl extension<br>
containing the contents of 'purelib' for a distribution, plus a<br>
Name-1.0.dist-info/ directory with the metadata files, plus<br>
Name-1.0.data/subdir directories for scripts, platlib, packaging's<br>
"categories", ...<br>
<br>
My specification so far is at<br>
<a href="https://docs.google.com/document/d/1mWPyvoeiqCrAy4UPNnvaz7Cgrqm4s_cfaTauAeJWABI/edit" target="_blank">https://docs.google.com/document/d/1mWPyvoeiqCrAy4UPNnvaz7Cgrqm4s_cfaTauAeJWABI/edit</a><br>
and an lxml compiled for linux-x86-64 is at<br>
<a href="https://docs.google.com/open?id=0BxHz5bC4iN5TN0VWTFNrZGtCbWs" target="_blank">https://docs.google.com/open?id=0BxHz5bC4iN5TN0VWTFNrZGtCbWs</a><br>
<br>
<a href="http://bitbucket.org/dholth/distribute" target="_blank">http://bitbucket.org/dholth/distribute</a><br>
<a href="http://github.com/dholth/pip" target="_blank">http://github.com/dholth/pip</a><br>
<a href="http://pypi.python.org/pypi/wheel" target="_blank">http://pypi.python.org/pypi/wheel</a><br>
<br>
Perhaps it will be useful. The implementation is still pretty rough,<br>
for example it does not check the architecture while installing, but<br>
it could be a handy way to speed up repeated virtualenv builds.<br>
<span class="HOEnZb"></span><br></blockquote></div><br>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. ;-)<br>
<br>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.<br>
<br>
</div></blockquote></body></html>