On Thu, Jan 21, 2016 at 11:54 AM, Matthias Klose <doko@ubuntu.com> wrote:
On 21.01.2016 17:13, Nathaniel Smith wrote:
On Jan 21, 2016 2:07 AM, "M.-A. Lemburg" <mal@egenix.com> wrote:
On 21.01.2016 10:31, Nick Coghlan wrote:
On 21 January 2016 at 19:03, M.-A. Lemburg <mal@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.
so this is x86_64-linux-gnu. Any other architectures?
That's by far the dominant architecture for Linux workstations and servers, so that's what we've focused on, yeah. I assume that mainstream glibc-using distros on x86-32 and ARM are similar; unless someone wants to go do the research somehow then I think the simplest way forward is to proceed on the assumption that the same spec will work, and then fix it up if/when it turns out to break.
Any reason to choose gcc 4.8.2 which is known for it's defects?
It's the most recent version of gcc that's able to target CentOS 5 (thanks to RH's backporting efforts in their "devtoolset" releases), and CentOS 5 is the target baseline that's currently used by approximately everyone who distributes universal linux binaries (google e.g. "holy build box").
This whole thing looks like an Anaconda marketing PEP ...
Anaconda's main selling point is that they provide binaries that "just work", and pip doesn't. Not sure how improving pip to be a stronger competitor to Anaconda is Anaconda marketing. -n -- Nathaniel J. Smith -- https://vorpus.org