On Jan 29, 2014, at 5:59 PM, Nick Coghlan <ncoghlan@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