[Distutils] wheels on sys.path clarification (reboot)

[Donald Stufft]

On Jan 29, 2014, at 5:59 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> But that's what I'm saying, there are only three ways to break this behaviour:
> 
> 1. Changing the wheel format in such a way that we drop support for being able to install simple wheel files without a specialised installer
> 2. Break zipimport itself to explicitly disallow wheel files
> 3. Switch to a zipimport incompatible compression scheme
> 
> The first two aren't going to happen, which leaves only the third.
> 
> 
> You appear to be saying that you would like to reserve the right to switch to a zipimport incompatible compression format in future versions of the wheel spec. If you're *not* saying that, then what independent design decision is there to be discussed that makes the new FAQ anything other than a clarification of the status quo? The rest of the behaviour is inherent in the "no specialised installer needed" feature.
> 
Eh, I think both 1 and 3 are things that are possibly reasonable to happen and
they are both things that I've contemplated as things to bring forward in
using xz as an alternative compression format. Even if #1 would need a major
revision of Wheel to happen adding official "support" for zip import means that
the change would have to be weighed against also breaking that backwards
compatibility.

> People saying "I didn't realise that the current design implied zipimport compatibility" is *why* I added the clarification, so it's not a compelling argument in convincing me that the clarification wasn't needed or is inappropriate.
> 
> Regards,
> Nick.
> 

I completely realized that the current design implied zip import compatibility,
but implicit features do not make features that we intend to support going
into the future. You're making the decision for us that we're not going to be
making these kinds of changes and even then it's really not about whether or
not this change can be removed or not.

For instance, pip supports installing from Wheels how long until we get a bug
report asking for the ability to install zipped Wheels? If we refuse to accept
it are we violating the spec? If we implement the spec as it stands are we
handing the users potential footguns?

It's more than just backwards compatibility concerns as well. I care about
providing the end users of these tools comprehensive solutions to the problems
they solve. By simply tacking a documented feature on after the PEP has been
accepted you're also removing the ability of this sig to arrive at such a
comprehensive solution. Instead what you get is "Well you can add a Wheel
directly to sys.path, except when you can't". This is user hostile.

Essentially a feature is more than the raw ability to do something, it also
includes documentation, support features, support infrastructure, etc. You've
removed the chance for this sig to participate in defining how we're going
to present this feature, what APIs around it we want to provide etc. Python is
a very dynamic language, just because you *can* do something doesn't mean it's
supported to actually do it.

The PEP process exists so that important decisions can be discussed and honed.
I want this change reverted and deferred to 1.1 so that we can follow the PEP
process and have this discussion. These seems like the most reasonable thing to
do and the thing that is most in spirit of the PEP process. It may be that
ultimately zip importable Wheels are added as a feature, hopefully with the
proper infrastructure to handle it sanely, but it is *wrong* to make the
decision that this a feature that Wheels officially support with first having
that discussion.

Finally I don't understand why reverting is such a controversial change with
you. As far as I can tell your rationale for adding this change is that it
would be difficult to remove support for it. In that case, and if it's truly
a thing that this sig wants to support as a desired feature, then I'm sure
the proponents of this particular feature will have no trouble getting it
formally accepted as part of Wheel 1.1 whereas inversely if it ends up being
a thing that this sig does *not* want to support, "removing" that feature is
much harder than "adding" it. The dialog is essentially being forced to be
"Why should we break this for people who depended on our documented feature"
which is a much harder thing to justify than "Why should we formally define
this feature".

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140129/32f5eab4/attachment.html>
-------------- 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/32f5eab4/attachment.sig>