<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>