[Distutils] Using Wheel with zipimport
Nick Coghlan
ncoghlan at gmail.com
Wed Jan 29 15:58:15 CET 2014
On 30 Jan 2014 00:28, "Vinay Sajip" <vinay_sajip at yahoo.co.uk> wrote:
>
> > It may be useful to understand that wheel has *political features* or
> > if you prefer *setting the defaults based on what we have learned from
> > eggs*. I don't recommend that they be zip-imported generally
> > but if you are a consenting adult who understands the caveats you
> > may do so.
>
> What *exactly* have we learned from eggs? We've learned that sys.path
> manipulation under the hood is bad, because sys.path is important to
system
> behaviour and because the ramifications of changing it under the hood are
unpredictable.
>
> But we don't let that lead to a mindset that prohibits *any* sys.path
manipulation - it's vital
> in many situations to be able to manipulate sys.path in a controlled way.
>
> What *else* have we learned from eggs? If we leave to one side the
sys.path manipulation
> issues, what else has been problematic about the egg format? Details seem
hard to find,
> though there's lots of talk in general about "pain" and "weirdness". I'm
asking because I
> really want to understand at a more detailed level what those problems
are, because I
> would be interested in trying to solve them, or minimise their impact.
That might sound
> naïve to some - but there it is.
I went through this with Chris McDonough back when packaging was dropped
from 3.3, and he really helped me focus on what I found to be the two
closely related core problems:
- implicit sys.path manipulation
- installing as eggs by default
That was due to easy_install defaults being chosen for the Chandler use
case rather than installing into a shared environment, but the egg format
(and zip imports in general) still ended up being tainted by association.
More recently, I've become concerned about the way setuptools/easy_install
assumes that an egg is zip import compatible in the absence of clear
markers that it isn't.
pip's wheel support avoids those issues, because the normal workflows just
install things normally. It takes special effort to go to the trouble of
keeping a wheel file *as* a wheel and then putting it on sys.path later.
distlib.mount already has the virtue of always being opt-in from the user
point of view, and the C extension support is opt-in from the publisher
point of view, but it would be improved by needing the publisher to opt in
to declaring support for zipimport (or meta imports in general), rather
than letting end users deal with debugging obscure errors from code that
assumes it has been fully installed.
Cheers,
Nick.
>
> Regards,
>
> Vinay Sajip
>
> _______________________________________________
> Distutils-SIG maillist - Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140130/25fc9696/attachment.html>
More information about the Distutils-SIG
mailing list