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

[Nathaniel Smith]

On Jan 27, 2016 3:47 AM, "Nick Coghlan" <ncoghlan at gmail.com> wrote:
>
> 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".

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).

So... here's some new text with the _manylinux module in it:
https://github.com/manylinux/manylinux/pull/14/files

and for now I've just put in the text that if you're a distributor,
then you should add this to the stdlib instead of treating it like a
regular package. I'm not sure if this is actually better than just
sticking an attribute in sys or something though.

Nick: I think this is the last issue before we're ready for
pronouncement, and you're the one who wants to keep the stdlib out of
it, so... what do you want to do? :-)

-n