On 29 January 2016 at 13:28, Nathaniel Smith <[email protected]> wrote: > On Thu, Jan 28, 2016 at 2:35 AM, Oscar Benjamin > <[email protected]> wrote: >> On 28 January 2016 at 07:46, Nathaniel Smith <[email protected]> wrote: >>> >>> On further thought, I realized that it actually has to be in the >>> standard library directory / namespace, and can't live in >>> site-packages: for the correct semantics it needs to be inherited by >>> virtualenvs; if it isn't then we'll see confusing rare problems. And >>> virtualenvs inherit the stdlib, but not the site-packages (in >>> general). >> >> Surely virtualenv can be made to import this information from the >> parent environment. It's already virtualenv's job to set up pip etc. >> so that you're ready to install things from PyPI. > > This doesn't seem like it would be attractive to distributors to me. > For them, it's just as easy either way to drop a file into > /usr/lib/python3.5/ versus /usr/lib/python3.5/site-packages. But if > you use site-packages/, you have to make sure you also have a patched > virtualenv and pyvenv, and worry about whether your distribution will > ever get used with old versions of virtualenv, etc., whereas if you > drop it into the stdlib directory then it just works robustly > everywhere. I guess we could put some finger-wagging in a PEP telling > them to use site-packages/, patch virtualenv, and eat their > vegetables, but I don't know why they'd listen to us :-).
We'd also be back in "patching the standard library" territory again, since we'd also have to modify venv. I like the simple approach Nathaniel now has in the PEP, as that seems like it should be relatively easy to handle as either modifications directly to a python package, or as an add-on module (ala installing LSB support, only much lighter weight). It doesn't scale to lots of platform tags, but we don't really intend it to - we'd like to avoid platform tag proliferation if we can, and if we're successful in that, then we won't need to solve the problem with a lack of scalability. Cheers, Nick. P.S. To provide a bit more context on "Why is a separate file easier?", the main benefit is that adding a new file simply *cannot* break the sys or platform modules, while patching them can. That's still not a guarantee that any given distro will actually provide an importable "_manylinux" module to indicate compatibility, but given the fallback glibc check, _manylinux is more a hedge against future *in*compatibility than it is anything else. -- Nick Coghlan | [email protected] | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
