[Distutils] Using Wheel with zipimport

[Donald Stufft]

On Jan 29, 2014, at 8:14 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 29 January 2014 22:57, Donald Stufft <donald at stufft.io> wrote:
>> Also to be specific, what I believe should be done is that the change should be
>> reverted, and if it is desired that Wheels officially support zip import then in the
>> next version of the Wheel spec it should be added when everyone has a chance
>> to properly discuss it.
> 
> Whether you like it or not, the wheel spec *does* already support
> being used that way, and changing it *would* be a backwards
> incompatible change to the format (and hence not acceptable without a
> compelling justification, and there isn't one that wouldn't equally
> well apply to other powerful but potentially confusing features like
> metaclasses and monkeypatching).
> 
> I am also not willing to allow the perception that the wheel format
> does not offer a strict superset of the feature of the egg format to
> persist until we have a defined wheel 1.1 spec (which we don't even
> have a volunteer to work on yet).
> 
> So, rather than removing it, I have instead updated the note in PEP 427 to read:
> 
> =============================
> Is it possible to import Python code directly from a wheel file?
>    Yes, the wheel format is deliberately designed to be compatible with
>    Python's support for importing from zip files, ensuring that it
>    provides a superset of the functionality provided by the preceding
>    egg format.
> 
>    However, this is generally not a *recommended* approach to using wheel
>    files, as importing from a zip file rather than an ordinary filesystem
>    directory imposes a number of additional constraints that will often
>    break the assumptions of Python developers (for example, C extensions
>    cannot be imported directly from a zip archive, and the ``__file__``
>    attribute no longer refers to an ordinary filesystem path, but to
>    a combination path that includes both the location of the zip archive
>    on the filesystem and the relative path to the module inside the
>    archive).
> 
>    Like metaclasses and metapath importers, if you're not sure if you need
>    to take advantage of this feature, you almost certainly don't need it.
> =============================
> 
> Regards,
> Nick.
> 
> -- 
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


So basically even though the text of the PEP specifically points out that a difference
of Wheel and Egg is that Eggs are importable it somehow supports that? Can you
point to a single line in the PEP that supports this besides the ones you’ve added?

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140129/8c0d27c2/attachment-0001.sig>