On 30 Jan 2014 00:28, "Vinay Sajip" <vinay_sa...@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@python.org > https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
