[Distutils] Using Wheel with zipimport

[Donald Stufft]

On Jan 29, 2014, at 2:32 AM, Nick Coghlan <ncoghlan at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140129/659319b3/attachment.sig>