[Distutils] wheels on sys.path clarification (reboot)

[Nick Coghlan]

I have clearly done a bad job so far of explaining the clarification in PEP
427, so here's a new attempt that relies solely on the PEP text and the way
the import system works, rather than the fact that the discussions around
the PEP show that the import system compatibility was a deliberate feature
that I took into account when accepting the PEP.

Here is the key quote from PEP 427:

"""Although a specialized installer is recommended, a wheel file may be
installed by simply unpacking into site-packages with the standard 'unzip'
tool while preserving enough information to spread its contents out onto
their final paths at any later time."""

That feature (which *is* explicitly documented in the accepted PEP),
ensures that there will always be a subset of wheel files which can be used
without needing a customised installer - just unzip them into a directory
on sys.path and go. Not all wheels will work that way, and there are some
downsides when you do it (e.g.  launch scripts won't be created and
bytecode files won't be compiled with elevated permissions if that is
needed). However, it's explicitly covered in the PEP and is an apparently
non-controversial design goal for the format.

Once you have that "can be installed just by unzipping the archive"
feature, then it is *an inherent property of how zipimport works* that
there will also be an even smaller subset of wheels that will work
correctly without even unpacking them first - you can just add the archive
directly to sys.path and let zipimport do its thing.

Aside from deliberately choosing a zipimport incompatible archive format
(which we didn't do), you cannot design a format that meets the first
requirement without inevitably also supporting the latter behaviour.
However, this fact isn't obvious (as has become eminently clear to me since
reading Armin Ronacher's recent wheel article), as not everyone is
intimately with the subtleties of the import system. That is why I added
the new text to the PEP - to make this capability clear without needing to
make that connection independently.

I do now plan to reword the new FAQ entry to make it clear that the import
compatibility is mainly a side effect of the "no specialised installer
needed" feature, but hopefully the above helps make it clear why this
compatibility is already an inherent feature of the accepted PEP rather
than something that can be discussed and accepted independently in a new
version - it is pointing out a non-obvious consequence of an existing
capability, not actually adding anything new.

Regards,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140130/f47f0ea7/attachment.html>