On Mon, Feb 1, 2016 at 3:47 PM, Alexander Walters <tritium-l...@sdamon.com> wrote:
> > > On 2/1/2016 18:37, Matthias Klose wrote: > >> On 30.01.2016 00:29, Nathaniel Smith wrote: >> >>> Hi all, >>> >>> I think this is ready for pronouncement now -- thanks to everyone for >>> all their feedback over the last few weeks! >>> >> >> I don't think so. I am biased because I'm the maintainer for Python in >> Debian/Ubuntu. So I would like to have some feedback from maintainers of >> Python in other Linux distributions (Nick, no, you're not one of these). >> >> The proposal just takes some environment and declares that as a >> standard. So everybody wanting to supply these wheels basically has to use >> this environment. Without giving any details, without giving any advise how >> to produce such wheels in other environments. Without giving any hints how >> such wheels may be broken with newer environments. Without mentioning this >> is am64/i386 only. >> There might be more. Pretty please be specific about your environment. >> Have a look how the LSB specifies requirements on the runtime environment >> ... and then ask yourself why the lsb doesn't have any real value. >> >> Matthias >> >> I... Thought the environment this pep describes is the docker image, and > only the docker image, and anything not made on that docker image is in > violation of the pep. It's not correct that anything made outside the docker image is in violation of the PEP. The docker images are just tools that can help you compile compliant wheels. Nathaniel and I tried to describe this as precisely as we could. See this section <https://www.python.org/dev/peps/pep-0513/#id32> of the PEP. To comply with the policy, the wheel needs to (a not link against any other external libraries beyond those mentioned in the PEP, (b) *work* on a stock CentOS 5.11 machine, and (c) not use any narrow-unicode symbols (only relevant for Python < 3.2). A consequence of requirements (a) and (b) is that versioned symbols that are referenced in the depended-upon shared libraries need to use sufficiently old versions of the symbols, which are noted in the PEP as well. In order to satisfy this aspect of the policy, the easiest route, from our experience, is to compile the wheel inside a CentOS 5 environment, but other routes are possible, including - statically link everything - use your favorite linux distro, but install an older version of glibc and configure your compiler to point to that. - use some inline assembly to instruct the linker to prefer older symbol versions in libraries like glibc. - etc. I also wrote the auditwheel command line tool that can check to see if a wheel is manylinux1 compatible, and give you some feedback about what to fix if it's not. And furthermore, I've just put up an example project on github that you can use as a template for compiling manylinux1 wheels using Travis-CI. You can find it here: https://github.com/pypa/python-manylinux-demo -Robert
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig