[Distutils] [final version?] PEP 513 - A Platform Tag for Portable Linux Built Distributions

[David Cournapeau]

On Tue, Feb 16, 2016 at 11:05 AM, Matthias Klose <doko at ubuntu.com> wrote:

> On 02.02.2016 02:35, Glyph Lefkowitz wrote:
>
>>
>> On Feb 1, 2016, at 3:37 PM, Matthias Klose <doko at ubuntu.com> wrote:
>>>
>>> On 30.01.2016 00:29, Nathaniel Smith wrote:
>>>
>>>> Hi all,
>>>>
>>>> I think this is ready for pronouncement now -- thanks to everyone for
>>>> all their feedback over the last few weeks!
>>>>
>>>
>>> I don't think so.  I am biased because I'm the maintainer for Python in
>>> Debian/Ubuntu.  So I would like to have some feedback from maintainers of
>>> Python in other Linux distributions (Nick, no, you're not one of these).
>>>
>>
>> Possibly, but it would be very helpful for such maintainers to limit
>> their critique to "in what scenarios will this fail for users" and not have
>> the whole peanut gallery chiming in with "well on _my_ platform we would
>> have done it _this_ way".
>>
>> I respect what you've done for Debian and Ubuntu, Matthias, and I use the
>> heck out of that work, but honestly this whole message just comes across as
>> sour grapes that someone didn't pick a super-old Debian instead of a
>> super-old Red Hat.  I don't think it's promoting any progress.
>>
>
> You may call this sour grapes, but in the light of people installing
> these wheels to replace/upgrade system installed eggs, it becomes an
> issue. It's fine to use such wheels in a virtual environment, however
> people tell users to use these wheels to replace system installed packages,
> distros will have a problem identifying issues.
>

FWIW, I often point out when people put "sudo" and "pip" in the same
sentence.

What about adding some language around this to the PEP ?


In the future, more specific and featureful distro tags sound like a good
>> idea.  But could we please stop making the default position on
>> distutils-sig "this doesn't cater to my one specific environment in the
>> most optimal possible way, so let's give up on progress entirely"?  This is
>> a good proposal that addresses environment portability and gives Python a
>> substantially better build-artifact story than it currently has, in the
>> environment most desperately needing one (server-side linux).  Could it be
>> better?  Of course.  It could be lots better.  There are lots of use-cases
>> for dynamically linked wheels and fancy new platform library features in
>> newer linuxes.  But that can all come later, and none of it needs to have
>> an impact on this specific proposal, right now.
>>
>
> I'm unsure how more specific and featureful distro tags will help, unless
> you start building more than one binary version of a wheel.  From a distro
> point of view I only can discourage using such wheels outside a virtual
> environment, and I would like to see a possibility to easily identify such
> wheels, something like loading a binary kernel module is tainting the
> kernel. This way distros can point users to the provider of such wheels.
>

This sounds like a good idea to me. Do you have a specific idea on how you
would like to see the feature work ?

David

>
> This is not a "this doesn't cater to my one specific environment"
> position. Of course you probably get less push back from other
> distributions closer to the specific environment specified in the pep.  But
> please acknowledge that there might be issues that you and me don't yet
> even see, and provide a possibility to identify such issues.
>
> At least Debian/Ubuntu took a long ride to avoid "accidental" interaction
> with local Python installations and local installations into the system
> installed Python.  For me this PEP feels like a step back, promising too
> much (manylinux), not pointing out possible issues, and giving no help in
> identifying possible issues with these wheels.
>
> Matthias
>
>
> _______________________________________________
> 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/20160216/cee96990/attachment.html>