On Jan 21, 2016 2:07 AM, "M.-A. Lemburg" <m...@egenix.com> wrote: > > 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).
The list of allowed libraries is exactly the same list of libraries as are required by the Anaconda python distribution, so we *know* that it works for about a hundred different python packages, including lots of tricky ones (the whole scientific stack), and had been tested by tens or hundreds of thousands of users. (I posted a link above to some actual working, compliant pyside and numpy packages, which we picked for testing because they're particular interesting/difficult packages that need to interface to external libraries.) Yes, various extra tricks are needed to get things working on top of this base, including strategies for shipping libraries that are not in the baseline set, but these are problems that can be solved on a project-by-project basis, and don't need a PEP. [...] > 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. There's no lock-in here -- any alternative approach just needs its own platform tag. Pypi and pip can easily support multiple such tags at the same time, if more sophisticated proposals arise in the future. In the mean time, for packagers targeting manylinux is at least as easy as targeting windows (which also provides very few libraries "for free"). -n
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
