On 22 January 2016 at 20:48, M.-A. Lemburg <m...@egenix.com> wrote: > People who rely on Linux distributions want to continue > to do so and get regular updates for system packages from > their system vendor. Having wheel files override these > system packages by including libs directly in the wheel > silently breaks this expectation, potentially opening > up the installations for security holes, difficult to > track bugs and possible version conflicts with already > loaded versions of the shared libs.
For the time being, these users should either pass the "--no-binary" option to pip, ask their distro to provide an index of pre-built wheel files for that distro (once we have the distro-specific wheel tagging PEP sorted out), or else ask their distro to update system Python packages in a more timely fashion (or all of the above). > IMO, that's much worse than having to install additional > system packages to make a Python wheel work. > > The embedding approach also creates licensing problems, > since those libs may be under different licenses than the > package itself. And of course, it increases the size of the > wheel files, causing more bandwidth to be necessary, > more disk space to be used for wheel caches, etc. Then *don't publish manylinux wheel files*. Manylinux is, by design, a platform+publisher-silo model, very similar to the way smart phone operating systems work, and the way Windows applications and (I believe) Mac App Bundles work. It is anti-thetical to the traditional tightly coupled shared everything model adopted by Linux distributions (where all the binaries are also generally built by a common central build system). There is a different model, which could be tagged as (for example) "integratedlinux1", which is the one you propose. That wouldn't be viable from a UX perspective without an external dependency description system like the one Tennessee proposed in https://github.com/pypa/interoperability-peps/pull/30, but that approach requires a lot more development work before it could be adopted. >From the point of view of future-proofing PEP 513 against having such an alternative available in the future, the main question that would need to be considered is how tools would decide download priority between a distro-specific wheel, an integrated linux wheel, and a linux wheel with bundled dependencies. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
