On 21.01.2016 17:13, Nathaniel Smith wrote:
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.
so this is x86_64-linux-gnu. Any other architectures? Any reason to choose gcc
4.8.2 which is known for it's defects? This whole thing looks like an Anaconda
marketing PEP ...
Matthias
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
