<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Jan 28, 2014, at 11:54 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"><br>
On 29 Jan 2014 11:19, "Daniel Holth" <<a href="mailto:dholth@gmail.com">dholth@gmail.com</a>> wrote:<br>
><br>
> On Tue, Jan 28, 2014 at 7:18 PM, Donald Stufft <<a href="mailto:donald@stufft.io">donald@stufft.io</a>> wrote:<br>
> ><br>
> > On Jan 28, 2014, at 6:38 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
> ><br>
> > I think you're reading too much into that comment. Putting a wheel file<br>
> > directly on sys.path is no different from putting any other zipfile directly<br>
> > on sys.path - whether or not it will work depends on the context, but it's a<br>
> > useful capability if used responsibly (as we do in the ensurepip<br>
> > implementation).<br>
> ><br>
> > The key problems with eggs in relation to this were:<br>
> > - easy_install preferring to install as eggs by default<br>
> > - setuptools install a global site hook that added every installed egg to<br>
> > sys.path for every application run in that Python installation<br>
> ><br>
> > Neither of those applies to wheels - pip always unpacks them when<br>
> > installing, and if you want to add one to sys.path you have to do it<br>
> > manually, it doesn't happen automatically.<br>
> ><br>
> > All the new note in the PEP is clarifying is that it *isn't* an accident<br>
> > that the wheel format is zipimport compatible for pure Python wheels, we<br>
> > deliberately designed it that way (hence the "Root-is-purelib" setting,<br>
> > rather than requiring separate purelib and platlib subdirectories).<br>
> ><br>
> > Cheers,<br>
> > Nick.<br>
> ><br>
> ><br>
> > Regardless if it was or wasn't an accident, I believe it was a mistake.<br>
> > Supporting it officially at all means that we have limitations on what we<br>
> > can<br>
> > do to make Wheel a better format. I had hopes that Wheel could be made more<br>
> > generic than it currently is, but because of the fact that directly adding<br>
> > them to sys.path is supported that makes it much much more awkward to do so.<br>
><br>
> Hey, as long as they are zipfiles that don't totally scramble the<br>
> layout of the internal Python code you can add them to sys.path. Did<br>
> you know you can even add subpaths of a zipfile to sys.path? </mind<br>
> blown></p><p dir="ltr">Yep, the only requirement is "there will be a non empty subset of valid wheel files that can be used directly with zipimport".</p><p dir="ltr">Wheels that include C extensions, or otherwise need to be unpacked to disk in order to work correctly aren't in that subset, and running directly from a wheel does prevent bytecode caching, but those are both OK - "supported when practical" isn't the same thing as "recommended".</p><p dir="ltr">Cheers,<br>
Nick.<br></p><p dir="ltr">><br>
> I'm opposed to making wheel generic as in "package PostgreSQL itself"<br>
> generic. There are other ways to do that.</p>
</blockquote></div><div><br></div>And yet on another read through of PEP427 the first item in “Comparison to Egg”<div>is "Wheel is an installation format; egg is importable.”. The only other mention of</div><div>importing any of them in that PEP is the section you just added saying that Wheels</div><div>are designed to be importable. The original text of the PEP does not provide any</div><div>evidence that Wheels were meant to be importable and instead makes it a point</div><div>to call that a difference from Eggs.</div><div><br></div><div>Further more there is a comment from Daniel on python-dev [1] which states that</div><div><br></div><div> “Jim Fulton is right that weird failures are a characteristic of zipped </div> eggs, so one of the #1 requests for setuptools is how to prohibit
<br> zipping from ever happening. This is an important reason why wheel is
<br> billed as an installation format -- fewer users with pitchforks. It's
<br> very cool that it works though. Debugging is slightly easier than it
<br> was in the old days because pdb can now read the source code from the
<br> zip.”<div><br></div><div>Which further shows that at the time it was “cool that it worked” but that the</div><div>“weird failures” being a reason that Wheel was an installation format.<br><div><div><br></div><div>I believe that adding this “feature” to the PEP ex post facto is a bad idea. Had the</div><div>PEP contained anything to indicate that Wheels were intended to be importable </div><div>as part of the design philosophy I would have spoken out about it then instead it’s</div><div>been added after it was accepted with no discussion that I can see.</div><div><br></div><div>If I missed where this discussion happened during the PEP please direct me to it</div><div>because I’ve just spent 15 minutes googling attempting to find any information on it,</div><div>and all I’ve been able to find is Vinay’s experiment with Wheel.mount(), You mentioning</div><div>the possibility of using Wheels in the sense of Multi Version Installs (which ends up</div><div>talking about a Wheel inspired directory layout instead), and the thread I mentioned</div><div>above. Not that it’s entirely relevant because really regardless of if it was discussed</div><div>if it wasn’t encoded in the PEP than people following along by watching the PEPs</div><div>had no ability to step in to speak for or against it.</div><div><div><br class="webkit-block-placeholder"></div><div>[1] <a href="https://groups.google.com/d/msg/dev-python/BS28mF7mb6c/o8jOo1NcousJ">https://groups.google.com/d/msg/dev-python/BS28mF7mb6c/o8jOo1NcousJ</a></div><div>
<br>-----------------<br>Donald Stufft<br>PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
</div>
<br></div></div></div></body></html>