On Jan 29, 2014, at 6:59 AM, Paul Moore <p.f.moore@gmail.com> wrote:
On 29 January 2014 11:41, Donald Stufft <donald@stufft.io> wrote:
On Jan 29, 2014, at 4:23 AM, Paul Moore <p.f.moore@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