[Distutils] PEP 513: A Platform Tag for Portable Linux Built Distributions Version

[Nick Coghlan]

On 29 January 2016 at 13:28, Nathaniel Smith <njs at pobox.com> wrote:
> On Thu, Jan 28, 2016 at 2:35 AM, Oscar Benjamin
> <oscar.j.benjamin at gmail.com> wrote:
>> On 28 January 2016 at 07:46, Nathaniel Smith <njs at pobox.com> 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   |   ncoghlan at gmail.com   |   Brisbane, Australia