On Thu, Jan 21, 2016 at 11:54 AM, Matthias Klose <[email protected]> wrote: > On 21.01.2016 17:13, Nathaniel Smith wrote: >> >> On Jan 21, 2016 2:07 AM, "M.-A. Lemburg" <[email protected]> wrote: >>> >>> >>> On 21.01.2016 10:31, Nick Coghlan wrote: >>>> >>>> On 21 January 2016 at 19:03, M.-A. Lemburg <[email protected]> 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 _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
