[Distutils] [final version?] PEP 513 - A Platform Tag for Portable Linux Built Distributions
njs at pobox.com
Tue Feb 16 15:45:41 EST 2016
On Feb 16, 2016 3:05 AM, "Matthias Klose" <doko at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Distutils-SIG