<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Jan 29, 2014, at 5:59 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><p dir="ltr">But that's what I'm saying, there are only three ways to break this behaviour:</p><p dir="ltr">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<br>
2. Break zipimport itself to explicitly disallow wheel files<br>
3. Switch to a zipimport incompatible compression scheme</p><p dir="ltr">The first two aren't going to happen, which leaves only the third.</p><div><br></div><p dir="ltr">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.</p></blockquote><div><div>Eh, I think both 1 and 3 are things that are possibly reasonable to happen and</div><div>they are both things that I've contemplated as things to bring forward in</div><div><div>using xz as an alternative compression format. Even if #1 would need a major</div><div>revision of Wheel to happen adding official "support" for zip import means that</div><div>the change would have to be weighed against also breaking that backwards</div><div>compatibility.</div><div><br></div></div></div><blockquote type="cite"><p dir="ltr">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.</p><p dir="ltr">Regards,<br>
Nick.</p>
</blockquote></div><div>I completely realized that the current design implied zip import compatibility,</div><div>but implicit features do not make features that we intend to support going</div><div>into the future. You're making the decision for us that we're not going to be</div><div>making these kinds of changes and even then it's really not about whether or</div><div>not this change can be removed or not.</div><div><br></div><div>For instance, pip supports installing from Wheels how long until we get a bug</div><div>report asking for the ability to install zipped Wheels? If we refuse to accept</div><div>it are we violating the spec? If we implement the spec as it stands are we</div><div>handing the users potential footguns?</div><div><br></div><div>It's more than just backwards compatibility concerns as well. I care about</div><div>providing the end users of these tools comprehensive solutions to the problems</div><div>they solve. By simply tacking a documented feature on after the PEP has been</div><div>accepted you're also removing the ability of this sig to arrive at such a</div><div>comprehensive solution. Instead what you get is "Well you can add a Wheel</div><div>directly to sys.path, except when you can't". This is user hostile.</div><div><br></div><div>Essentially a feature is more than the raw ability to do something, it also</div><div>includes documentation, support features, support infrastructure, etc. You've</div><div>removed the chance for this sig to participate in defining how we're going</div><div>to present this feature, what APIs around it we want to provide etc. Python is</div><div>a very dynamic language, just because you *can* do something doesn't mean it's</div><div>supported to actually do it.</div><div><br></div><div>The PEP process exists so that important decisions can be discussed and honed.</div><div>I want this change reverted and deferred to 1.1 so that we can follow the PEP</div><div>process and have this discussion. These seems like the most reasonable thing to</div><div>do and the thing that is most in spirit of the PEP process. It may be that</div><div>ultimately zip importable Wheels are added as a feature, hopefully with the</div><div>proper infrastructure to handle it sanely, but it is *wrong* to make the</div><div>decision that this a feature that Wheels officially support with first having</div><div>that discussion.</div><div><br></div><div>Finally I don't understand why reverting is such a controversial change with</div><div>you. As far as I can tell your rationale for adding this change is that it</div><div>would be difficult to remove support for it. In that case, and if it's truly</div><div>a thing that this sig wants to support as a desired feature, then I'm sure</div><div>the proponents of this particular feature will have no trouble getting it</div><div>formally accepted as part of Wheel 1.1 whereas inversely if it ends up being</div><div>a thing that this sig does *not* want to support, "removing" that feature is</div><div>much harder than "adding" it. The dialog is essentially being forced to be</div><div>"Why should we break this for people who depended on our documented feature"</div><div>which is a much harder thing to justify than "Why should we formally define</div><div>this feature".</div><div>
<br>-----------------<br>Donald Stufft<br>PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
</div>
<br></body></html>