> On Jan 24, 2016, at 7:08 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > > On 24 January 2016 at 12:31, Robert T. McGibbon <rmcgi...@gmail.com> wrote: >> On Sat, Jan 23, 2016 at 6:19 PM, Chris Barker <chris.bar...@noaa.gov> wrote: >>> >>> 1) each package that needs a third partly lib statically links it in. >>> 2) each package that needs a third partly lib provides it, linked with a >>> relative path (IIUC, that's how most Windows packages are done. >>> 3) We establish some standard for providing binary libs as wheels, so that >>> other packages can depend on them and link to them. >> >> In my view, all of these are valid options. I think much of this will need >> to be worked out by the communities -- especially if individual packages and >> subcommunities decide to take the option (3) approach. I hope this PEP will >> enable the communities involved in OpenGIS, audio processing, image >> processing, etc to work out the solutions that work for them and their >> users. >> >> Perhaps one thing that is missing from the PEP is an explicit statement that >> option (3) is compatible with the manylinux1 tag -- bundling is a valid >> solution, but it's not the *only* solution. > > I've long resisted the notion of defining our own cross-distro > platform ABI, but the Docker build environment that was put together > for the manylinux project has made me realise that doing that may not > be as hellish in a post-Docker world as it would have been in a > pre-Docker world. (Since we can go with the specification + reference > implementation approach that CPython has used so successfully for so > long, rather than having to have the build environment and ABI > specification be entirely exhaustive). > > On Windows and Mac OS X, our binary compatibility policies for wheel > files are actually pretty loose - it's "be binary compatible with the > python.org builds for that platform, including linking against the > appropriate C standard library", and that's about it. Upgrades to > those ABIs are then driven by CPython switching to newer base > compatibility levels (dropping end-of-life versions on the Windows > side [1], and updating to new deployment target macros on the Mac OS X > side). Folks with external dependencies either bundle them, skip > publishing wheel files, or just let them fail at import time if the > external dependency is missing. (Neither platform has an anti-bundling > culture, though, so I assume a lot of folks go with the first option > over the last one) > > If the aim is to bring Linux wheel support in line with Windows and > Mac OS X, then rather than defining a *new* compatibility tag (which > would require new pip clients to process), perhaps we could instead > adopt a similarly loose policy on what the existing generic "linux" > tag means as we have for Windows and Mac OS X: it could just mean > wheel files that are binary compatible with the Python binaries in the > "manylinux" build environment. The difference would then just be that > the target Linux ABI would be defined by PyPA and the manylinux > developers, rather than by python-dev. > > In terms of the concerns regarding the age of gcc needed to target > CentOS 5.11, it would be good to know just what nominating CentOS 6.x > as the baseline ABI instead would buy us - CentOS 5 is going on 9 > years old (released 2007) and stopped receiving full updates back in > 2014 [2], while RHEL/CentOS 6 is just over 5 years old and has another > year of full updates left. The CentOS 6 ABI should still be old enough > to be compatible with the Debian 6 ABI (current stable is Debian 8), > as well as the Ubuntu 12.04 LTS ABI (Ubuntu 16.04 LTS is due out in a > few months). >
It's probably not worth it to try and reuse the existing linux tags. Prior to the release of pip 8, pip had a hardcoded check to not trust linux wheels from PyPI, even if one was allowed to be uploaded, because we weren't sure if some change was going to be required in pip to support whatever solution we come up with for linux wheels and we didn't want a bunch of old pip's to suddenly start getting wheels they didn't know how to install. After thinking about it more, I decided that installing wheels are pretty simple and it's unlikely pip is going to have to change anything to support that particular tag, so in pip 8 I removed that hack. So it's been less than a week that a version of pip has existed that would install the generic linux platform anyways. There is a similar sort of project to try and make it easy to build cross distro compatible C/C++ things, called the "Holy Build Box" [1] so that certainly lends some extra weight behind the whole idea. Another thing to consider is applicablity outside of Python. When I was talking about the manylinux thing with some friends, one of them mentioned that they were interested in the same thing, but for the Rust language. If we define the manylinux platform, it may make sense to promote it to something that isn't so Python specific and define two things, the manylinux platform (possibly we can buy some domain name for it or something), and then a PEP that just integrates that platform with Python. Might not be worth it though. [1] https://phusion.github.io/holy-build-box/ ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
