[Distutils] Using Wheel with zipimport

[Donald Stufft]

On Jan 29, 2014, at 6:59 AM, Paul Moore <p.f.moore at gmail.com> wrote:

> On 29 January 2014 11:41, Donald Stufft <donald at stufft.io> wrote:
>> 
>> On Jan 29, 2014, at 4:23 AM, Paul Moore <p.f.moore at gmail.com> wrote:
>> 
>>> 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 just read every version of the PEP that has ever existed in Mercurial
>> and no version besides Nick's most recent contains any text about
>> the importability of Wheels besides that one of the differences of
>> Wheel and Egg is that Wheel is an installation format and Egg is
>> importable.
> 
> Apologies. It was something Daniel pointed out a few times very early
> on - I hadn't realised it wasn't in the spec directly.
> 
> What is in the spec - which effectively constrains the format to
> *allowing* (rather than encouraging) direct import - are the facts
> that wheels are zip format, and that one of purelib/platlib is at the
> root. The concept of separating "unpack" and "spread" and the comment
> "Although a specialized installer is recommended, a wheel file may be
> installed by simply unpacking into site-packages" doesn't leave any
> room for wheels *not* to be importable in the majority of pure-python,
> no package data, cases.
> 
> Debating how we present this in later versions of the wheel spec is
> fine. But deliberately making wheels not importable would break
> backward compatibility in a way that would have other, likely more
> serious, implications.
> 
> Nevertheless, I understand your concerns, and I think we should be
> very careful not to let people get the impression that this is in any
> way similar to "importable eggs", which had a very bad press.
> 
> Paul

I read that statement differently, in that it doesn’t guarantee that the files
would be at the *root* of the Wheel, just that you could unpack a Wheel
into a site-packages directory using unzip and have it be “installed”. I can
see how it could be read otherwise though. In either case this is something
that is more able to be removed in later versions of Wheel because
unpacking by hand is something I don’t believe will ever be commonplace,
and any installer that doesn’t check it’s Wheel version before doing things
with the Wheel is wrong.

But more importantly, while I’m against officially supporting importable Wheels
because of various reasons, my biggest problem is that this was added in
without any chance for discussion. I don’t think anyone can call me a casual
observer of distutils-sig or the various PEP processes and this was the first
time that I had heard of Wheels being importable as anything other than a
sometimes useful hack that wasn’t a design goal but instead just an accident
of implementation. I followed the PEP closely trying to make sure that we
weren’t going to add a supported feature that locked us into any corners while
the format was still new and this is something I would have fought against
had it been in the original PEP.

Nick may have, in his head, considered this to be a feature of Wheel all along
and not an implementation detail, however that is not what the PEP stated. I
don’t believe that as BDFL-Delegate for packaging issues Nick should be able
to add supported features to an already accepted PEP without discussion
especially when the existing text of that PEP is directly contrary to that feature
being part of the PEP.

-----------------
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/1e287102/attachment.sig>