[Distutils] Using Wheel with zipimport

[Nick Coghlan]

On 29 Jan 2014 11:19, "Daniel Holth" <dholth at gmail.com> wrote:
>
> On Tue, Jan 28, 2014 at 7:18 PM, Donald Stufft <donald at stufft.io> wrote:
> >
> > On Jan 28, 2014, at 6:38 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> >
> > I think you're reading too much into that comment. Putting a wheel file
> > directly on sys.path is no different from putting any other zipfile
directly
> > on sys.path - whether or not it will work depends on the context, but
it's a
> > useful capability if used responsibly (as we do in the ensurepip
> > implementation).
> >
> > The key problems with eggs in relation to this were:
> > - easy_install preferring to install as eggs by default
> > - setuptools install a global site hook that added every installed egg
to
> > sys.path for every application run in that Python installation
> >
> > Neither of those applies to wheels - pip always unpacks them when
> > installing, and if you want to add one to sys.path you have to do it
> > manually, it doesn't happen automatically.
> >
> > All the new note in the PEP is clarifying is that it *isn't* an accident
> > that the wheel format is zipimport compatible for pure Python wheels, we
> > deliberately designed it that way (hence the "Root-is-purelib" setting,
> > rather than requiring separate purelib and platlib subdirectories).
> >
> > Cheers,
> > Nick.
> >
> >
> > Regardless if it was or wasn't an accident, I believe it was a mistake.
> > Supporting it officially at all means that we have limitations on what
we
> > can
> > do to make Wheel a better format. I had hopes that Wheel could be made
more
> > generic than it currently is, but because of the fact that directly
adding
> > them to sys.path is supported that makes it much much more awkward to
do so.
>
> Hey, as long as they are zipfiles that don't totally scramble the
> layout of the internal Python code you can add them to sys.path. Did
> you know you can even add subpaths of a zipfile to sys.path? </mind
> blown>

Yep, the only requirement is "there will be a non empty subset of valid
wheel files that can be used directly with zipimport".

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

Cheers,
Nick.

>
> I'm opposed to making wheel generic as in "package PostgreSQL itself"
> generic. There are other ways to do that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140129/53869927/attachment.html>