On 29 January 2014 05:52, Donald Stufft <donald@stufft.io> wrote:
Which further shows that at the time it was "cool that it worked" but that the "weird failures" being a reason that Wheel was an installation format.
Having "cool" features in a format is not a bad thing. Zip imports are the "cool " feature here - they have been used for lots of really impressive things (like py2exe, for a less controversial example). But they have limitations (which become "weird failures" when people try to use the feature without knowing or catering for the limitations) and it's the responsibility of the user to understand and address those limitations - or not use the feature if the limitations are too great for them.
I believe that adding this "feature" to the PEP ex post facto is a bad idea. Had the PEP contained anything to indicate that Wheels were intended to be importable as part of the design philosophy I would have spoken out about it then instead it's been added after it was accepted with no discussion that I can see.
As I recall, it was in the original version of the PEP/spec and it was always an intended feature. The wheel file for the wheel project itself is (deliberately) runnable as a zip file, so that you can bootstrap into the wheel world using the "wheel install" command. I do *not* recommend using wheels as a runtime format if the package in the wheel hits any of the limitations of zipimport (C extensions, data files that are not or cannot be accessed via pkgutil.package_data, etc). I also would not recommend using wheels except in *very* specialised circumstances (where you have the wheel already and cannot easily just install it before use - pip, ensurepip, virtualenv and similar distribution-oriented environments are the key use cases here). But I do think the feature is useful and should be supported. Paul.