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.

pep-0427.txt

@@ -400,23 +400,42 @@ What's the deal with "purelib" vs. "platlib"?
 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