On Tue, Feb 16, 2016 at 11:05 AM, Matthias Klose <d...@ubuntu.com> wrote:
> On 02.02.2016 02:35, Glyph Lefkowitz wrote: > >> >> On Feb 1, 2016, at 3:37 PM, Matthias Klose <d...@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@python.org > https://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig