On 29 January 2014 22:57, Donald Stufft <donald@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@gmail.com | Brisbane, Australia