On 23.01.2016 04:26, Nick Coghlan wrote: > On 22 January 2016 at 22:07, M.-A. Lemburg <m...@egenix.com> wrote: >> However, system vendors will often be a lot faster with updates >> than package authors, simply because it's their business model, >> so as user you will want to benefit from those updates and >> not have to rely on the package author to ship new wheel files. > > This is true for the subset of packages monitored by distro security > response teams, but there's a *lot* of software not currently packaged > for Linux distros that never will be as more attention is given to the > "rebuild the world on demand" model that elastic cloud computing and > fast internet connections enable. > > My fundamental concern is that if a package author publishes a distro > dependent wheel file, pip attempts to install it, and it doesn't work, > the reaction for many users is going to be "Python packaging is > broken", not "the packaging of this particular package is broken".
I think helping the user to identify where the problem originates is certainly possible. This can be done in a generic way by e.g. having pip or the wheel package scan the wheel file for shared libraries using ldd and finding potentially missing libs. Or we could define a special package post install entry point which pip calls to have the wheel itself check the system it was installed on for missing system packages or any other post install actions that need to take place before the wheel file can be used, e.g. setting up initial config files. > However, moving the "generic linux wheels are ignored by default" > behaviour to pip-the-client, rather than enforcing it as a restriction > on PyPI uploads could definitely be a reasonable alternative way of > addressing that concern. I don't think that's the right strategy. There are certainly ways to improve error reporting for Python packaging (see above), but outright rejecting generic wheels is not a good approach, IMO. The wheel system is not yet complete, but until it is, using a "we want to protect the user from failing wheels" approach is not going to help much, since we're just replacing this with a "we'll let the user handle failing source installations" approach instead - with the main reason apparently being that we want to avoid putting the user blame for failures on PyPI, pip or wheels. This ignores that fact that generic wheels have a much better chance of success than source installations of the same package on the same system (it's rather unlikely that the user will have the foo-dev package installed with the corresponding foo binary package). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Jan 23 2016) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ________________________________________________________________________ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/ _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
