On Jan 29, 2014, at 2:32 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
All of those arguments are against *recommending* directly importing from wheels. Yes, there are lots of problems with running directly from a zip archive, which is why the fact that easy_install *actively encourages* potentially inexperienced users to run things that way is so problematic.
However, for people that are comfortable with the import system and the limitations of direct zip imports, it's a very useful feature. I wouldn't have accepted PEP 427 without the zipimport compatibility that meant a developer *could* use it as a direct replacement for eggs if they really wanted to.
Otherwise we'd have to define a whole new format for something that can be adequately handled by a wheel that meets certain restrictions, and that would be pointless (we already have too many formats, and we wanted the wheel format to offer a strict superset of the egg format's capabilities).
I clarified PEP 427 specifically because Armin Ronacher's wheel article showed that he was unaware of this *deliberately included* feature of the wheel format. People are free not to like it - the default tools deliberately make it less convenient to run things that way, and that's as it should be. However, it's not a super-secret capability only to be used by us to implement things like ensurepip - it's a defined capability of the format that if your software is capable of running correctly from a zip archive in the first place, then that archive can be also be a valid wheel file.
Running directly from a wheel is a power tool - that's a reason to put "handle with care" warnings on it, not to refuse to support a feature that was deliberately designed into the format. You can do a lot more damage with a badly written meta-importer, yet we have no intention of deprecating that capability either. Even *.pth files have turned out to have a valid use case for sharing packages between virtual environments.
We have lots of features like that elsewhere in Python - when people ask about metaclasses, the first reaction is "You probably don't want to use them". However, sometimes developers *do* need them, and that's why the feature exists. Most of the time developers won't want to make use of the zipimport compatibility of wheel files, either, but advanced use cases like ensurepip are exactly why the capability exists.
I can make the new note in the PEP more explicit that while this is a supported use case that ensures the feature set provided by wheels is a strict superset of that provided by eggs, that's not the same thing as *recommending* that wheels be used that way.
Cheers, Nick.
I don’t think it particularly matters wether you would have accepted the PEP without that ability or not. You *did* accept the PEP when the text of the PEP directly pointed out that one of the differences of Wheel and Egg were that “Wheel is an installation format, Egg is importable” which points to that fact that Wheel was not designed to be importable. As far as I can tell you’ve added this “feature” to the PEP by fiat without any chance for anyone to be able to discuss it after it’s already been accepted. I’m well aware that we cannot prevent Wheels from being imported, but that’s another thing all together from directly supporting it. For one thing by supporting it we forever lock ourselves into dumping what would be in site-packages directly in the root of the Wheel because adding the .whl file directly to sys.path is now a documented feature. This behavior has personally caused me annoyance and one of the things I was hoping on doing in a Wheel 1.2 was revise the layout a bit to make installation simpler and make inspecting a Wheel file easier. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA