On Fri, Jan 22, 2016 at 10:26 PM, Nick Coghlan <[email protected]> wrote:
> On 22 January 2016 at 22:07, M.-A. Lemburg <[email protected]> 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". > This is already broken with source dists if you don't have the appropriate -dev packages (or a compiler) installed. Some package authors provide more useful feedback explaining what the problem is and how one might resolve it, rather than dying on a compiler error due to a missing header, but many do not. One solution to this for both source and binary distributions is package manager awareness in the build/install tools, and to have packages declare their dependencies in structured metadata. A translational layer would make this easier on package authors: If they only had to say they depend on "OpenSSL headers" and that was translated to the correct package for the OS, this could be relayed to the user at build time ("install these packages using this command") or the package manager could be directly invoked, if the user has chosen to allow the build/install tool to do that. --nate > 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. > > Cheers, > Nick. > > -- > Nick Coghlan | [email protected] | Brisbane, Australia > _______________________________________________ > Distutils-SIG maillist - [email protected] > https://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
