On 21.01.2016 10:31, Nick Coghlan wrote: > On 21 January 2016 at 19:03, M.-A. Lemburg <m...@egenix.com> wrote: >> By using the version based approach, we'd not run into this >> problem and gain a lot more. > > I think it's better to start with a small core that we *know* works, > then expand later, rather than trying to make the first iteration too > wide. The "manylinux1" tag itself is versioned (hence the "1" at the > end), so "manylinux2" may simply have *more* libraries defined, rather > than newer ones.
My argument is that the file based approach taken by the PEP is too limiting to actually make things work for a large set of Python packages. It will basically only work for packages that do not interface to other external libraries (except for the few cases listed in the PEP, e.g. X11, GL, which aren't always installed or available either). IMO, testing the versions of a set of libraries is a safer approach. It's perfectly fine to have a few dependencies not work in a module because an optional system package is not installed, e.g. say a package comes with UIs written in Qt and one in GTK. pip could then warn about missing dependencies in the installed packages. Another detail we have found when external dependencies is that some platforms use different names for the libraries, e.g. RedHat has a tendency to use non-standard OpenSSL library names (/lib64/libssl.so.10 instead of the more common libssl.so.1.0.0). > The key is that we only have one chance to make a good first > impression with binary Linux wheel support on PyPI, and we want that > to be positive for everyone: Sure, but if we get the concept wrong, it'll be difficult to switch later on and since there will always be libs not in the set, we'll need to address this in some way. > * for publishers, going from "no Linux wheels" to "Linux wheels if you > have few external dependencies beyond glibc" is a big step up (it's > enough for a Cython accelerator module, for example, or a cffi wrapper > around a bundled library) > * for end users, we need to nigh certain that wheels built this way > will *just work* > > Even with a small starting list of libraries defined, we're going to > end up with cases where the installed extension module will fail to > load, and end users will have to figure out what dependencies are > missing. The "external dependency specification" at > https://github.com/pypa/interoperability-peps/pull/30 would let pip > detect that at install time (rather the user finding out at runtime > when the module fails to load), but that will still leave the end user > to figure out how to get the external dependencies installed. > > If Donald can provide the list of "most downloaded wheel files" for > other platforms, that could also be a useful guide as to how many > source builds may potentially already be avoided through the draft > "manylinux1" definition. I still believe that installers are in a better position to decide which binary files to install based on the findings on the installation system. This is why we are using a more flexible tag system in our prebuilt format: http://www.egenix.com/library/presentations/PyCon-UK-2014-Python-Web-Installer/ In essence, the installer knows which files are available and can then analyze the installation system to pick the right binary. Tags can be added as necessary to address all the different dimensions that need testing, e.g. whether the binary runs on a Raspi2 or only a Raspi1. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Jan 21 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
