[Distutils] [final version?] PEP 513 - A Platform Tag for Portable Linux Built Distributions
cournape at gmail.com
Tue Feb 16 09:43:12 EST 2016
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
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 ?
> 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.
> Distutils-SIG maillist - Distutils-SIG at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Distutils-SIG