<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 16, 2016 at 11:05 AM, Matthias Klose <span dir="ltr"><<a href="mailto:doko@ubuntu.com" target="_blank">doko@ubuntu.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 02.02.2016 02:35, Glyph Lefkowitz wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Feb 1, 2016, at 3:37 PM, Matthias Klose <<a href="mailto:doko@ubuntu.com" target="_blank">doko@ubuntu.com</a>> wrote:<br>
<br>
On 30.01.2016 00:29, Nathaniel Smith wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
I think this is ready for pronouncement now -- thanks to everyone for<br>
all their feedback over the last few weeks!<br>
</blockquote>
<br>
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).<br>
</blockquote>
<br>
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".<br>
<br>
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.<br>
</blockquote>
<br></span>
You may call this sour grapes, but in the light of people installing<br>
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.<br></blockquote><div><br></div><div>FWIW, I often point out when people put "sudo" and "pip" in the same sentence.<br><br></div><div>What about adding some language around this to the PEP ?<br><span class=""></span><br><span class="">
</span><br><span class="">
</span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br></span>
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.<br></blockquote><div><br></div><div>This sounds like a good idea to me. Do you have a specific idea on how you would like to see the feature work ?<br><br></div><div>David<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
<br>
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.<span class="HOEnZb"><font color="#888888"><br>
<br>
Matthias</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org" target="_blank">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</div></div></blockquote></div><br></div></div>