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

[Xavier Fernandez]

Well, the way I read the pep is that manylinux1 is a policy and also the
name of a wheel platform tag.
The policy has nothing special except the fact that it is the first one. I
think everyone agrees that if this successfully enables linux wheels, there
is no reason we won't have any other tags, maybe more focused on some
subset of libraries.
I don't think we want to have a _tag_module for each new type of tag.

I personally like:
sys.supported_platform_tags = ["manylinux2_x86_64"]
sys.unsupported_platform_tags = set(["manylinux1_x86_64"])
but the platform module seems even more appropriate than the sys one.

But this still needs to touch the standard library.

So maybe the simplest solution would be to leave this to pip config.
I personally liked the idea of this PR:
https://github.com/pypa/pip/pull/3092 that would gives the possibility from
linux to "pip download lxml --platform=win-amd64" in order to download
win-amd64 compatible wheels.
We could imagine a similar option for "pip install
--platforms=manylinux2,manylinux1 lxml".

pip already looks for its options in several places so maybe the OS
distribution could drop the compatibility information in one of these
places (like /etc/pip.conf...).

-- 
Xavier

On Wed, Jan 27, 2016 at 10:36 PM, Nathaniel Smith <njs at pobox.com> wrote:

> 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>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160127/e291234f/attachment.html>