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

[Nathaniel Smith]

On Wed, Jan 27, 2016 at 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".
>
> 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.
>

Fair enough -- how about we use "_manylinux" to emphasize that this is an
internal module (as opposed to e.g. some package you'd get on pypi that
provides manylinux-related functionality)? It doesn't have as many features
as Xavier's suggestion of exporting a generic preference-ordered list
combining manylinux tags, distro-specific tags, etc., but that seems a bit
premature right now and could always be added on top later (_wheel_tags.py
can import _manylinux).

-n

-- 
Nathaniel J. Smith -- https://vorpus.org <http://vorpus.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160127/bfb09034/attachment-0001.html>