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

[Nick Coghlan]

On 27 January 2016 at 08:36, Nathaniel Smith <njs at pobox.com> wrote:
> On Mon, Jan 25, 2016 at 8:37 PM, Robert T. McGibbon <rmcgibbo at gmail.com> wrote:
>> I agree that this is an important detail. I generally use machines that have
>> many different Python interpreters installed (some distro-provided and
>> others in my home directory), and can easily imagine wanting them to have
>> different behavior w.r.t. manylinux1 wheels.
>>
>> Perhaps the option could be put in site.py, or somewhere in
>> lib/pythonX.Y/configX.Y/? I'm not sure what the appropriate solution here
>> is.
>
> On further thought, the site.py solution has sorta grown on me...
> basically the PEP text would look something like:
>
> "If there exists an attribute sys._manylinux1_compatible, then
> bool(sys._manylinux1_compatible) determines whether the given
> interpreter should be considered manylinux1-compatible. By default,
> upstream Python builds will not provide any variable with this name,
> but a distributor may create it if they choose (e.g. from
> sitecustomize.py)."
>
> It's not exactly pretty, but it's kinda elegant: it neatly solves the
> problem of binding the configuration to an individual python
> environment, allows it to be set from site.py or sitecustomize.py or
> from a user's PYTHONSTARTUP or usercustomize.py or even by a local
> patch to the interpreter, it's naturally inherited across
> virtualenv/venvs, can be checked in very little code, and can be
> specified in very few words.
>
> I guess we can bikeshed about whether 'sys' is the appropriate place :-)

I'd prefer to leave standard library modules out of this if we can -
they're a rabbit warren of political complexity, even when upstream
and redistributors agree on what needs to be done (since
redistributors have customers, and having people pay you tends to make
them even *less* forgiving if you change something in a way that
breaks their systems).

However, I do like the idea of defining a *Python* API for accessing
the configuration data as the initial solution. Since nothing in the
standard library needs it, it can just be an ordinary module called
"manylinux".

If "import manylinux" fails, then we're in the "compatibility not
specified" case (or we're not on a Linux system).

If "import manylinux" works, then the module can give details (perhaps
pulled from a config file, perhaps figured out on the fly by querying
the running system, perhaps hardcoded by the OS vendor) on the
compatibility level.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia