> 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. But now that we have identified that it was "by association", we can hopefully make more informed decisions and not throw the baby out with the bath-water. > 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. That's a measured response to a specific concern: it makes sense to codify the publisher's intent in the wheel (with a sensible default) and to have distlib's Wheel.mount() take into account the publisher's intent when considering whether to allow mounting of a wheel to take place. Regards, Vinay Sajip _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
