On Feb 16, 2016 3:05 AM, "Matthias Klose" <d...@ubuntu.com> wrote: [...] > > 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.
Like Paul, I don't understand how wheels change any this -- everything in the above paragraph is just as true if you s/wheel/sdist/, isn't it? "sudo pip install" was a bad idea before and is a bad now, for sure. > There is a substantial amount of extensions built using C++; I didn't check how many of these in c++0x/c++11 mode. Until GCC 5, the c++11 ABI wasn't stable, and upstream never promised forward compatibility, something that even distros have to care about (usually by rebuilding packages before a release). So if you want a lowest common denominator, then maybe limit or recommend the use of c++98 only. I'm not sure what the situation with the C++11 abi is in detail (do you mean backwards compatibility?), but in any case your wish is preemptively granted :-). The libstdc++ in centos5 doesn't contain c++11 support, so in manylinux1 wheels you are allowed to use C++11 if and only if you can find some way to provide your own self-contained runtime support that doesn't rely on the system libstdc++. (The devtoolset compilers are handy in that they are configured to do this automatically.) [...] > 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 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. I guess it should be possible to implement such a tool by scanning the .dist-info directories of installed packages? It's certainly true that installing random packages off pypi into system directories (and running those packages' setup.py code as root!) can create arbitrarily terrible breakage. (I guess wheels at least remove the root code execution. Why does pip even allow itself to be run as root? It's certainly not written in a paranoid security-first style.) And I agree that unexpected issues may arise in particular packages. But again it's not clear to me how wheels create a special/unique problem that calls for a special/unique countermeasure. Surely the first line of defense for detecting such things is just "does the traceback mention /usr/local", which is the same with or without wheels? I assume you are already used to detecting "sudo pip" users in bug reports and pointing them to the provider of these wheels or sdists? What about your workflow are you hoping to change? -n
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
