http://hg.python.org/peps/rev/26983acc9c11 changeset: 5367:26983acc9c11 user: Nick Coghlan <ncoghlan@gmail.com> date: Thu Jan 30 22:07:45 2014 +1000 summary: PEP 427: emphasise the preference for installation The zipimport compatibility isn't an accident, but relying on it is still a great way to create obscure bugs for yourself if you don't already know exactly what you're doing. files: pep-0427.txt | 49 +++++++++++++++++++++++++++------------ 1 files changed, 34 insertions(+), 15 deletions(-) diff --git a/pep-0427.txt b/pep-0427.txt --- a/pep-0427.txt +++ b/pep-0427.txt @@ -400,23 +400,42 @@ 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. + Technically, a subset of wheel files *do* support being placed directly + on ``sys.path`` (due to the combination of supporting installation + via simple extraction and using an archive format that is compatible + with ``zipimport``), but actually doing so is generally discouraged. - 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). + Firstly, wheel *is* designed primarily as an installation format, so + skipping the installation step means deliberately avoiding any reliance + on features that assume full installation (such as being able to use + standard tools like ``pip`` and ``virtualenv`` to capture and manage + dependencies in a way that can be properly tracked for auditing and + security update purposes, or integrating fully with the standard + build machinery for C extensions by publishing header files in the + appropriate place). - 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. + Secondly, while some Python software is written to support running + directly from a zip archive, it is still common for code to be written + assuming it has been fully installed. When that assumption is broken + by trying to run the software from a zip archive, the failures can often + be obscure and hard to diagnose (especially when they occur in third + party libraries). The two most common sources of problems with this + are the fact that importing C extensions from a zip archive is *not* + supported by CPython (since doing so is not supported directly by the + dynamic loading machinery on any platform) and that when running from + a zip archive 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). Even when software + uses the abstract resource APIs correctly internally, interfacing with + external components may still require the available of an actual on-disk + file. + + Like metaclasses, monkeypatching and metapath importers, if you're not + already sure you need to take advantage of this feature, you almost + certainly don't need it. If you *do* decide to use it anyway, be + aware that many projects will require a failure to be reproduced with + a fully installed package before accepting it as a genuine bug. References -- Repository URL: http://hg.python.org/peps