Re: [Distutils] draft PEP: manylinux1

On Fri, Jan 29, 2016 at 11:44 PM, Donald Stufft wrote: > > On Jan 29, 2016, at 2:35 PM, Nate Coraor wrote: > > Is there a distro-specific wheel tagging PEP in development somewhere that > I missed? If not, I will get the ball rolling on it. > > > > I think

Re: [Distutils] draft PEP: manylinux1

On Fri, Jan 29, 2016 at 9:14 PM, Nick Coghlan wrote: > On 30 January 2016 at 05:30, Nate Coraor wrote: > > I wonder if, in relation to this, it may be best to have two separate > tags: > > one to indicate that the wheel includes external libraries rolled in

Re: [Distutils] draft PEP: manylinux1

> On Jan 29, 2016, at 8:44 PM, Donald Stufft wrote: > > >> On Jan 29, 2016, at 2:35 PM, Nate Coraor > > wrote: >> >> Is there a distro-specific wheel tagging PEP in development somewhere that I >> missed? If not, I will get the

Re: [Distutils] draft PEP: manylinux1

On Fri, Jan 29, 2016 at 11:35 AM, Nate Coraor wrote: > On Fri, Jan 22, 2016 at 6:29 AM, Nick Coghlan wrote: >> >> On 22 January 2016 at 20:48, M.-A. Lemburg wrote: >> > People who rely on Linux distributions want to continue >> > to do so

Re: [Distutils] draft PEP: manylinux1

On 30 January 2016 at 05:35, Nate Coraor wrote: > On Fri, Jan 22, 2016 at 6:29 AM, Nick Coghlan wrote: >> For the time being, these users should either pass the "--no-binary" >> option to pip, ask their distro to provide an index of pre-built wheel >> files

Re: [Distutils] draft PEP: manylinux1

On 30 January 2016 at 05:30, Nate Coraor wrote: > I wonder if, in relation to this, it may be best to have two separate tags: > one to indicate that the wheel includes external libraries rolled in to it, > and one to indicate that it doesn't. That way, a user can make a conscious

Re: [Distutils] draft PEP: manylinux1

> On Jan 29, 2016, at 2:35 PM, Nate Coraor wrote: > > Is there a distro-specific wheel tagging PEP in development somewhere that I > missed? If not, I will get the ball rolling on it. I think this a great idea, and I think it actually pairs nicely with the manylinux

Re: [Distutils] draft PEP: manylinux1

On Fri, Jan 22, 2016 at 5:42 AM, Nick Coghlan wrote: > On 22 January 2016 at 19:33, M.-A. Lemburg wrote: > > For example, if a package needs a specific version of libpng, > > the package author can document this and the user can then make > > sure to install

Re: [Distutils] draft PEP: manylinux1

On Fri, Jan 22, 2016 at 10:26 PM, Nick Coghlan wrote: > On 22 January 2016 at 22:07, M.-A. Lemburg wrote: > > However, system vendors will often be a lot faster with updates > > than package authors, simply because it's their business model, > > so as user

Re: [Distutils] draft PEP: manylinux1

On Fri, Jan 22, 2016 at 6:29 AM, Nick Coghlan wrote: > On 22 January 2016 at 20:48, M.-A. Lemburg wrote: > > People who rely on Linux distributions want to continue > > to do so and get regular updates for system packages from > > their system vendor. Having

Re: [Distutils] draft PEP: manylinux1

On Thu, Jan 21, 2016 at 6:31 PM, Nathaniel Smith wrote: > On Thu, Jan 21, 2016 at 2:22 PM, Nate Coraor wrote: > > Could this instead use the more powerful json-based syntax proposed by > Nick > > here: > > > > >

Re: [Distutils] draft PEP: manylinux1

On 27 January 2016 at 22:54, Nick Coghlan wrote: > I followed this up with the ABI folks, and the problem is that the > elfutils in even DTS 2 is too old to support building libabigail, and > later versions of the developer toolset (3 & 4) don't support being > run on CentOS

Re: [Distutils] draft PEP: manylinux1

> On Jan 27, 2016, at 12:00 PM, David Cournapeau wrote: > > So now, one could argue that it is not the community's job to tackle old OS, > and they would be right, but: We can make a data driven decision here. Here is the top 100 *nix OSs that are downloading files from

Re: [Distutils] draft PEP: manylinux1

On Wed, Jan 27, 2016 at 4:37 PM, Chris Barker wrote: > > > On Wed, Jan 27, 2016 at 1:37 AM, David Cournapeau > wrote: > >> >> I will make sure to let the manylinux effort know when we decide to move >> to Centos6 as the base system. >> > > Thanks -- do

Re: [Distutils] draft PEP: manylinux1

On Wed, Jan 27, 2016 at 1:37 AM, David Cournapeau wrote: > > I will make sure to let the manylinux effort know when we decide to move > to Centos6 as the base system. > Thanks -- do you have any idea how many of your customers are running systems that old? i.e. have you

Re: [Distutils] draft PEP: manylinux1

> On Jan 27, 2016, at 12:29 PM, David Cournapeau wrote: > > > > On Wed, Jan 27, 2016 at 5:18 PM, Donald Stufft > wrote: > >> On Jan 27, 2016, at 12:00 PM, David Cournapeau > >

Re: [Distutils] draft PEP: manylinux1

On Wed, Jan 27, 2016 at 5:18 PM, Donald Stufft wrote: > > On Jan 27, 2016, at 12:00 PM, David Cournapeau wrote: > > So now, one could argue that it is not the community's job to tackle old > OS, and they would be right, but: > > > We can make a data driven

Re: [Distutils] draft PEP: manylinux1

On Jan 27, 2016 09:00, "David Cournapeau" wrote: > [...] > The main argument against using centos 5 is GUI-related components, as the old fontconfig/glib (the GTK one, not Gnu libc) are a problem. But those are a tiny minority of what people do with python nowadays, and they

Re: [Distutils] draft PEP: manylinux1

> On Jan 27, 2016, at 12:37 PM, Nathaniel Smith wrote: > > Is the kernel version table you mentioned trivial to get? I bet it's very > closely correlated with glibc version. https://gist.github.com/dstufft/1eaa826361ac5b755f17

Re: [Distutils] draft PEP: manylinux1

On Wed, Jan 27, 2016 at 5:43 PM, Nathaniel Smith wrote: > On Jan 27, 2016 09:00, "David Cournapeau" wrote: > > > [...] > > The main argument against using centos 5 is GUI-related components, as > the old fontconfig/glib (the GTK one, not Gnu libc) are a

Re: [Distutils] draft PEP: manylinux1

On Jan 27, 2016 09:18, "Donald Stufft" wrote: > > >> On Jan 27, 2016, at 12:00 PM, David Cournapeau wrote: >> >> So now, one could argue that it is not the community's job to tackle old OS, and they would be right, but: > > > We can make a data driven

Re: [Distutils] draft PEP: manylinux1

Tl;dr: Looks like the oldest kernel that makes the top 100 list is 2.6.32, which is used in both RHEL6 and Debian 6. On Jan 27, 2016 9:50 AM, "Donald Stufft" wrote: > > On Jan 27, 2016, at 12:37 PM, Nathaniel Smith wrote: > > Is the kernel version table you

Re: [Distutils] draft PEP: manylinux1

On Wed, Jan 27, 2016 at 12:02 AM, Chris Barker wrote: > On Tue, Jan 26, 2016 at 3:56 PM, Nathaniel Smith wrote: >> >> Well, the people who know what they're doing are still recommending >> CentOS 5 today, and we don't know what we're doing :-). >> > >

Re: [Distutils] draft PEP: manylinux1

On 26 January 2016 at 23:17, Nick Coghlan wrote: > On 26 January 2016 at 21:44, Antoine Pitrou wrote: >> On Tue, 26 Jan 2016 20:36:26 +1000 >> Nick Coghlan wrote: >>> >>> If I understand the problem correctly, the CentOS 5 gcc

Re: [Distutils] draft PEP: manylinux1

On 26 January 2016 at 16:49, Robert T. McGibbon wrote: > On Mon, Jan 25, 2016 at 10:29 PM, Chris Barker - NOAA Federal > wrote: >> >> Given that we're starting now ( not a year or two ago) and it'll take >> a while for it to really catch on, we should

Re: [Distutils] draft PEP: manylinux1

Isnt the entire point of using centos 5 to use an ancient toolchain? On 1/26/2016 06:44, Antoine Pitrou wrote: On Tue, 26 Jan 2016 20:36:26 +1000 Nick Coghlan wrote: If I understand the problem correctly, the CentOS 5 gcc toolchain is old enough that it simply doesn't emit

Re: [Distutils] draft PEP: manylinux1

On Tue, 26 Jan 2016 06:50:15 -0500 Alexander Walters wrote: > Isnt the entire point of using centos 5 to use an ancient toolchain? No, the point is to link against an ancient glibc. The toolchain can be modern (and actually has to if you want to compile e.g. C++11 code).

Re: [Distutils] draft PEP: manylinux1

On Tue, 26 Jan 2016 20:36:26 +1000 Nick Coghlan wrote: > > If I understand the problem correctly, the CentOS 5 gcc toolchain is > old enough that it simply doesn't emit the info libabigail needs in > order to work. If you build on CentOS 5, you certainly want to use the RH

Re: [Distutils] draft PEP: manylinux1

On 26 January 2016 at 21:44, Antoine Pitrou wrote: > On Tue, 26 Jan 2016 20:36:26 +1000 > Nick Coghlan wrote: >> >> If I understand the problem correctly, the CentOS 5 gcc toolchain is >> old enough that it simply doesn't emit the info libabigail needs in

Re: [Distutils] draft PEP: manylinux1

On Mon, Jan 25, 2016 at 10:49 PM, Robert T. McGibbon wrote: > On Mon, Jan 25, 2016 at 10:29 PM, Chris Barker - NOAA Federal < > chris.bar...@noaa.gov> wrote: > >> Given that we're starting now ( not a year or two ago) and it'll take >> a while for it to really catch on, we

Re: [Distutils] draft PEP: manylinux1

On Tue, Jan 26, 2016 at 11:47 AM, Chris Barker wrote: > On Mon, Jan 25, 2016 at 10:49 PM, Robert T. McGibbon > wrote: >> >> On Mon, Jan 25, 2016 at 10:29 PM, Chris Barker - NOAA Federal >> wrote: >>> >>> Given that we're starting

Re: [Distutils] draft PEP: manylinux1

On Tue, Jan 26, 2016 at 4:02 PM, Chris Barker wrote: > On Tue, Jan 26, 2016 at 3:56 PM, Nathaniel Smith wrote: >> >> Well, the people who know what they're doing are still recommending >> CentOS 5 today, and we don't know what we're doing :-). > > > well,

Re: [Distutils] draft PEP: manylinux1

On Tue, Jan 26, 2016 at 11:44 AM, Antoine Pitrou wrote: > On Tue, 26 Jan 2016 20:36:26 +1000 > Nick Coghlan wrote: > > > > If I understand the problem correctly, the CentOS 5 gcc toolchain is > > old enough that it simply doesn't emit the info libabigail

Re: [Distutils] draft PEP: manylinux1

On Mon, Jan 25, 2016 at 10:29 PM, Chris Barker - NOAA Federal < chris.bar...@noaa.gov> wrote: > Given that we're starting now ( not a year or two ago) and it'll take > a while for it to really catch on, we should go CentOS 6 ( or > equivalent ) now? > > CentOS5 was released in 2007! That is a

Re: [Distutils] draft PEP: manylinux1

On Sun, Jan 24, 2016 at 8:37 PM, Nick Coghlan wrote: [...] >> ...well, or maybe just erroring out when it sees the future and asking >> the user to help would be good enough :-). This would impose the >> requirement going forward that we'd have to wait for a pip release >>

Re: [Distutils] draft PEP: manylinux1

(e.g. by bumping up >> the base ABI from CentOS 5 to CentOS 6). > > The problem with this is that python 2.7 is going to be supported and > widely used until well past the EOL of CentOS 5, and maybe even past > the EOL of CentOS 6 Given that we're starting now ( not a year or two ago) and it'll

Re: [Distutils] draft PEP: manylinux1

On Sat, Jan 23, 2016 at 6:19 PM, Chris Barker wrote: > OK, > > I'll try to stop being emotional here :-) > >> 2016-01-22 3:47 GMT+01:00 Chris Barker - NOAA Federal >> : >> > >> > I'm skeptical because I >> > tried to to that for years for OS-X and it

Re: [Distutils] draft PEP: manylinux1

> On Jan 24, 2016, at 7:21 PM, Nathaniel Smith wrote: > > Maybe we need wheel-builders-sig? Their mandate would be to hash out > things like how to build binary-libraries-wrapped-up-in-wheels, share > knowledge about the minutiae of linker behavior on different platforms > (oh

Re: [Distutils] draft PEP: manylinux1

On 25 January 2016 at 08:32, Nathaniel Smith wrote: > On Sun, Jan 24, 2016 at 4:08 AM, Nick Coghlan wrote: >> 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

Re: [Distutils] draft PEP: manylinux1

On 25 January 2016 at 10:23, Donald Stufft wrote: > >> On Jan 24, 2016, at 7:21 PM, Nathaniel Smith wrote: >> >> Maybe we need wheel-builders-sig? Their mandate would be to hash out >> things like how to build binary-libraries-wrapped-up-in-wheels, share >>

Re: [Distutils] draft PEP: manylinux1

On 24 January 2016 at 12:31, Robert T. McGibbon wrote: > On Sat, Jan 23, 2016 at 6:19 PM, Chris Barker 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,

Re: [Distutils] draft PEP: manylinux1

> On Jan 24, 2016, at 7:08 AM, Nick Coghlan wrote: > > On 24 January 2016 at 12:31, Robert T. McGibbon wrote: >> On Sat, Jan 23, 2016 at 6:19 PM, Chris Barker wrote: >>> >>> 1) each package that needs a third partly lib

Re: [Distutils] draft PEP: manylinux1

On Sun, Jan 24, 2016 at 4:08 AM, Nick Coghlan wrote: > On 24 January 2016 at 12:31, Robert T. McGibbon wrote: >> On Sat, Jan 23, 2016 at 6:19 PM, Chris Barker wrote: >>> >>> 1) each package that needs a third partly lib statically

Re: [Distutils] draft PEP: manylinux1

> On Jan 24, 2016, at 5:32 PM, Nathaniel Smith wrote: > > The one thing that does give me pause is that whenever we *do* decide > to switch to manylinux2, then it's going to be a big drag to wait for > a whole pip release/upgrade cycle -- Debian unstable is still shipping > pip

Re: [Distutils] draft PEP: manylinux1

> On Jan 24, 2016, at 2:56 PM, Donald Stufft wrote: > > ... the excellent Barry Warsaw ... Distro work is often thankless (especially here) so I just wanted to echo this: glory to the FLUFL, may his reign be <> short. -glyph___

Re: [Distutils] draft PEP: manylinux1

On 23.01.2016 04:26, Nick Coghlan wrote: > On 22 January 2016 at 22:07, M.-A. Lemburg wrote: >> However, system vendors will often be a lot faster with updates >> than package authors, simply because it's their business model, >> so as user you will want to benefit from those

Re: [Distutils] draft PEP: manylinux1

On Sat, Jan 23, 2016 at 6:19 PM, Chris Barker 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. >

Re: [Distutils] draft PEP: manylinux1

OK, I'll try to stop being emotional here :-) 2016-01-22 3:47 GMT+01:00 Chris Barker - NOAA Federal >: > > > > I'm skeptical because I > > tried to to that for years for OS-X and it was just too much to do. And > the > > infrastructure was there. > > My point is that

Re: [Distutils] draft PEP: manylinux1

On Jan 22, 2016 9:04 AM, "Lowekamp, Bradley (NIH/NLM/LHC) [C]" < blowek...@mail.nih.gov> wrote: > > Hello, > > I noticed that libpython is missing from the lists of dependent libraries. Also the “manylinux” Docker image has it’s Python versions compiled with libpython static. > > Does this mean

Re: [Distutils] draft PEP: manylinux1

On 22.01.2016 11:03, Nathaniel Smith wrote: > On Fri, Jan 22, 2016 at 1:33 AM, M.-A. Lemburg wrote: >> On 21.01.2016 20:05, Matthew Brett wrote: >>> Hi, >>> >>> On Thu, Jan 21, 2016 at 2:05 AM, M.-A. Lemburg wrote: On 21.01.2016 10:31, Nick Coghlan wrote:

Re: [Distutils] draft PEP: manylinux1

On 22 January 2016 at 07:04, Matthew Brett wrote: >> That's an interesting idea, but I personally don't see the manylinux1 list >> as particularly >> "scientific". If anything, I'd call it "minimal". > > Yes, I agree, I don't think 'linux-sciabi1" would differentiate this

Re: [Distutils] draft PEP: manylinux1

On Fri, Jan 22, 2016 at 1:33 AM, M.-A. Lemburg wrote: > On 21.01.2016 20:05, Matthew Brett wrote: >> Hi, >> >> On Thu, Jan 21, 2016 at 2:05 AM, M.-A. Lemburg wrote: >>> On 21.01.2016 10:31, Nick Coghlan wrote: On 21 January 2016 at 19:03, M.-A. Lemburg

Re: [Distutils] draft PEP: manylinux1

On 21.01.2016 20:05, Matthew Brett wrote: > Hi, > > On Thu, Jan 21, 2016 at 2:05 AM, M.-A. Lemburg wrote: >> On 21.01.2016 10:31, Nick Coghlan wrote: >>> On 21 January 2016 at 19:03, M.-A. Lemburg wrote: By using the version based approach, we'd not run

Re: [Distutils] draft PEP: manylinux1

On 22 January 2016 at 17:04, Matthew Brett wrote: > Hi, > On Thu, Jan 21, 2016 at 7:45 PM, Robert T. McGibbon > wrote: >> On Thu, Jan 21, 2016 at 7:32 PM, Nick Coghlan wrote: >>> However, it does suggest a possible alternative

Re: [Distutils] draft PEP: manylinux1

2016-01-22 3:47 GMT+01:00 Chris Barker - NOAA Federal : > > Maybe the community will spring forth and do that -- I'm skeptical because I > tried to to that for years for OS-X and it was just too much to do. And the > infrastructure was there. > > Before pip and wheel there

Re: [Distutils] draft PEP: manylinux1

On 22 January 2016 at 20:48, M.-A. Lemburg wrote: > People who rely on Linux distributions want to continue > to do so and get regular updates for system packages from > their system vendor. Having wheel files override these > system packages by including libs directly in the

Re: [Distutils] draft PEP: manylinux1

On 22 January 2016 at 21:25, Donald Stufft wrote: > Thinking of it in terms of a C like "undefined behavior" is probably a > reasonable way of doing it. Linking against a system provided library that is > on this list is a defined behavior of the manylinux "platform", linking >

Re: [Distutils] draft PEP: manylinux1

> On Jan 22, 2016, at 6:29 AM, Nick Coghlan wrote: > > On 22 January 2016 at 20:48, M.-A. Lemburg wrote: >> People who rely on Linux distributions want to continue >> to do so and get regular updates for system packages from >> their system vendor. Having

Re: [Distutils] draft PEP: manylinux1

On 22 January 2016 at 11:55, Donald Stufft wrote: >> From the point of view of future-proofing PEP 513 against having such >> an alternative available in the future, the main question that would >> need to be considered is how tools would decide download priority >> between a

Re: [Distutils] draft PEP: manylinux1

> On Jan 22, 2016, at 5:48 AM, M.-A. Lemburg wrote: > > Embedding additional libraries in the wheels files to overcome > deficiencies in the PEP design simply doesn't feel right > to me. > > People who rely on Linux distributions want to continue > to do so and get regular

Re: [Distutils] draft PEP: manylinux1

On 22.01.2016 12:25, Donald Stufft wrote: > >> On Jan 22, 2016, at 5:48 AM, M.-A. Lemburg wrote: >> >> Embedding additional libraries in the wheels files to overcome >> deficiencies in the PEP design simply doesn't feel right >> to me. >> >> People who rely on Linux

Re: [Distutils] draft PEP: manylinux1

objects from different patch versions at runtime? I checked Anaconda, and they are using a shared Python library. Thanks, Brad From: Nathaniel Smith [n...@pobox.com] Sent: Wednesday, January 20, 2016 10:55 PM To: distutils-sig Subject: [Distutils] draft PEP

Re: [Distutils] draft PEP: manylinux1

On 21 January 2016 at 23:30, Leonardo Rochael Almeida wrote: > I think it would be nice to have the following options as well: > > --no-binary-from > --only-binary-from > > This way I could block binaries from PyPI but allow from my private index > where they were compiled

Re: [Distutils] draft PEP: manylinux1

Hi Nathaniel and Robert, This is a really nice proposal. I would only like to see added to this proposal (or another one) that new versions of installers should offer an option to opt in or out of binary packages from specific sources. Right now pip has the switches: - --no-binary -

Re: [Distutils] draft PEP: manylinux1

On 21.01.2016 11:11, Nick Coghlan wrote: > On 21 January 2016 at 20:05, M.-A. Lemburg wrote: >> On 21.01.2016 10:31, Nick Coghlan wrote: >>> On 21 January 2016 at 19:03, M.-A. Lemburg wrote: By using the version based approach, we'd not run into this

Re: [Distutils] draft PEP: manylinux1

After I posted the PEP link on social media, a friend of mine, Kyle Beauchamp, asked: "I wonder if there are speed and correctness implications to always reverting to the lowest common denominator of glibc." For speed, I believe there is some consequence, in that the maximum gcc version you can

Re: [Distutils] draft PEP: manylinux1

On 21 January 2016 at 20:05, M.-A. Lemburg wrote: > On 21.01.2016 10:31, Nick Coghlan wrote: >> On 21 January 2016 at 19:03, M.-A. Lemburg wrote: >>> By using the version based approach, we'd not run into this >>> problem and gain a lot more. >> >> I think it's

Re: [Distutils] draft PEP: manylinux1

On 21 January 2016 at 19:03, M.-A. Lemburg 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

Re: [Distutils] draft PEP: manylinux1

On Thu, Jan 21, 2016 at 1:31 AM, Nick Coghlan wrote: > > 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),

Re: [Distutils] draft PEP: manylinux1

On 21.01.2016 10:31, Nick Coghlan wrote: > On 21 January 2016 at 19:03, M.-A. Lemburg 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

Re: [Distutils] draft PEP: manylinux1

Robert McGibbon: Thanks for writing up this PEP :-) Some comments below... On 21.01.2016 04:55, Nathaniel Smith wrote: > The ``manylinux1`` policy > = > > For these reasons, to achieve broad portability, Python wheels > > * should depend only on an extremely limited

Re: [Distutils] draft PEP: manylinux1

On 21.01.2016 17:13, Nathaniel Smith wrote: > On Jan 21, 2016 2:07 AM, "M.-A. Lemburg" wrote: >> >> On 21.01.2016 10:31, Nick Coghlan wrote: >>> On 21 January 2016 at 19:03, M.-A. Lemburg wrote: By using the version based approach, we'd not run into this

Re: [Distutils] draft PEP: manylinux1

> On Jan 21, 2016, at 12:18 PM, Donald Stufft wrote: > > >> On Jan 21, 2016, at 4:31 AM, Nick Coghlan wrote: >> >> If Donald can provide the list of "most downloaded wheel files" for >> other platforms, that could also be a useful guide as to how many >>

Re: [Distutils] draft PEP: manylinux1

On Jan 21, 2016 2:07 AM, "M.-A. Lemburg" wrote: > > On 21.01.2016 10:31, Nick Coghlan wrote: > > On 21 January 2016 at 19:03, M.-A. Lemburg wrote: > >> By using the version based approach, we'd not run into this > >> problem and gain a lot more. > > > > I think

Re: [Distutils] draft PEP: manylinux1

> On Jan 20, 2016, at 10:55 PM, Nathaniel Smith wrote: > > The permitted external shared libraries are: :: > >libpanelw.so.5 >libncursesw.so.5 >libgcc_s.so.1 >libstdc++.so.6 >libm.so.6 >libdl.so.2 >librt.so.1 >libcrypt.so.1 >libc.so.6 >

Re: [Distutils] draft PEP: manylinux1

On Thu, Jan 21, 2016 at 8:53 AM, M.-A. Lemburg wrote: > [...] > What we need is a system that provides a few dimensions > for various system specific differences (e.g. bitness, > architecture) and a recommendation for library > versions of a few very basic libraries to use when

Re: [Distutils] draft PEP: manylinux1

nice, idea, but libX11.so.6 libXext.so.6 libXrender.so.1 libGL.so.1 These are all X11, yes? pretty much any workstation will have these, but in general, servers won't. Someone on this thread suggested that that's OK -- don't expect a GUI package to work on a linux box

Re: [Distutils] draft PEP: manylinux1

On Thu, Jan 21, 2016 at 11:37 AM, Nathaniel Smith wrote: > Glyph told us last week that this proposal is exactly how the > cryptography package wants to handle their openssl dependency: > https://www.mail-archive.com/distutils-sig@python.org/msg23506.html > > well, SSL is a

Re: [Distutils] draft PEP: manylinux1

On Thu, Jan 21, 2016 at 11:48 AM, Matthew Brett wrote: > > So without a plan to provide all that stuff -- I"m not sure of the > utility > > of this -- how are you gong to get PIL/Pillow to work? statically link up > > the ying-yang? Not sure the linux world will take to

Re: [Distutils] draft PEP: manylinux1

On 21 January 2016 at 19:37, Nathaniel Smith wrote: >> Right now, no one can upload Linux wheels, so that a fair >> setup. > > The fairness that I'm more worried about is that right now Windows and OSX > users get wheels, and Linux users don't. Feature parity across these >

Re: [Distutils] draft PEP: manylinux1

> On Thu, Jan 21, 2016 at 11:55 AM, Robert T. McGibbon > wrote: > >> >> > These are all X11, yes? pretty much any workstation will have these, >> but in general, servers won't. >> > >> > Someone on this thread suggested that that's OK -- don't expect a GUI >> package to work

Re: [Distutils] draft PEP: manylinux1

On Jan 21, 2016 11:55 AM, "Chris Barker" wrote: > > On Thu, Jan 21, 2016 at 11:37 AM, Nathaniel Smith wrote: >> >> Glyph told us last week that this proposal is exactly how the cryptography package wants to handle their openssl dependency:

Re: [Distutils] draft PEP: manylinux1

On 21.01.2016 17:13, Nathaniel Smith wrote: On Jan 21, 2016 2:07 AM, "M.-A. Lemburg" wrote: On 21.01.2016 10:31, Nick Coghlan wrote: On 21 January 2016 at 19:03, M.-A. Lemburg wrote: By using the version based approach, we'd not run into this problem and

Re: [Distutils] draft PEP: manylinux1

> On Jan 21, 2016, at 1:43 PM, Nathaniel Smith wrote: > > On Jan 21, 2016 9:32 AM, "Donald Stufft" > wrote: > > > > > > > On Jan 20, 2016, at 10:55 PM, Nathaniel Smith > > > wrote: > > > > >

Re: [Distutils] draft PEP: manylinux1

On Jan 21, 2016 12:04 PM, "Matthias Klose" wrote: > 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? I'm not aware of those defects. Can you share more information? -Robert

Re: [Distutils] draft PEP: manylinux1

On Thu, Jan 21, 2016 at 11:54 AM, Matthias Klose wrote: > On 21.01.2016 17:13, Nathaniel Smith wrote: >> >> On Jan 21, 2016 2:07 AM, "M.-A. Lemburg" wrote: >>> >>> >>> On 21.01.2016 10:31, Nick Coghlan wrote: On 21 January 2016 at 19:03, M.-A. Lemburg

Re: [Distutils] draft PEP: manylinux1

> On Jan 21, 2016, at 4:31 AM, Nick Coghlan wrote: > > If Donald can provide the list of "most downloaded wheel files" for > other platforms, that could also be a useful guide as to how many > source builds may potentially already be avoided through the draft > "manylinux1"

Re: [Distutils] draft PEP: manylinux1

On 21.01.2016 04:55, Nathaniel Smith wrote: the choice of compiler is questionable. Just a pick into a release series. Not even the last released version on this release series. Is this a good choice? Maybe for x86_64 and i386, but not for anything else. The permitted external shared

Re: [Distutils] draft PEP: manylinux1

> On Jan 21, 2016, at 3:14 PM, Nathaniel Smith wrote: > > On Thu, Jan 21, 2016 at 11:54 AM, Matthias Klose wrote: >> On 21.01.2016 17:13, Nathaniel Smith wrote: >>> >>> On Jan 21, 2016 2:07 AM, "M.-A. Lemburg" wrote: On

Re: [Distutils] draft PEP: manylinux1

On Jan 21, 2016 12:08 PM, "Donald Stufft" wrote: > > >> On Jan 21, 2016, at 1:43 PM, Nathaniel Smith wrote: >> >> On Jan 21, 2016 9:32 AM, "Donald Stufft" wrote: >> > >> > >> > > On Jan 20, 2016, at 10:55 PM, Nathaniel Smith

Re: [Distutils] draft PEP: manylinux1

On Thu, Jan 21, 2016 at 8:18 PM, Matthias Klose wrote: > On 21.01.2016 04:55, Nathaniel Smith wrote: > > the choice of compiler is questionable. Just a pick into a release > series. Not even the last released version on this release series. Is this > a good choice? Maybe for

Re: [Distutils] draft PEP: manylinux1

On Thu, 21 Jan 2016 11:42:57 -0800 Chris Barker wrote: > nice, idea, but > > libX11.so.6 > libXext.so.6 > libXrender.so.1 > libGL.so.1 > > These are all X11, yes? pretty much any workstation will have these, but in > general, servers won't. For the

Re: [Distutils] draft PEP: manylinux1

On Thu, Jan 21, 2016 at 10:04 PM, David Cournapeau wrote: > > > On Thu, Jan 21, 2016 at 7:42 PM, Chris Barker > wrote: > >> nice, idea, but >> >> libX11.so.6 >> libXext.so.6 >> libXrender.so.1 >> libGL.so.1 >> >> These are all X11,

Re: [Distutils] draft PEP: manylinux1

On Thu, Jan 21, 2016 at 1:31 AM, Nick Coghlan wrote: > 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

Re: [Distutils] draft PEP: manylinux1

Nathaniel, Robert, I'm really excited to see how quickly you're making progress. A few comments below as I haven't had a chance to catch up on the day's discussion: On Wed, Jan 20, 2016 at 10:55 PM, Nathaniel Smith wrote: > Building on the compability lessons learned from these

Re: [Distutils] draft PEP: manylinux1

On Thu, Jan 21, 2016 at 2:22 PM, Nate Coraor wrote: > Nathaniel, Robert, I'm really excited to see how quickly you're making > progress. A few comments below as I haven't had a chance to catch up on the > day's discussion: > > On Wed, Jan 20, 2016 at 10:55 PM, Nathaniel Smith

Re: [Distutils] draft PEP: manylinux1

On Thu, Jan 21, 2016 at 11:05 AM, Matthew Brett wrote: > Hi, > > On Thu, Jan 21, 2016 at 2:05 AM, M.-A. Lemburg wrote: >> On 21.01.2016 10:31, Nick Coghlan wrote: >>> On 21 January 2016 at 19:03, M.-A. Lemburg wrote: By using the

Re: [Distutils] draft PEP: manylinux1

Hi, On Thu, Jan 21, 2016 at 11:57 AM, Chris Barker wrote: > On Thu, Jan 21, 2016 at 11:48 AM, Matthew Brett > wrote: >> >> > So without a plan to provide all that stuff -- I"m not sure of the >> > utility >> > of this -- how are you gong to get

Re: [Distutils] draft PEP: manylinux1

Hi, On Thu, Jan 21, 2016 at 11:42 AM, Chris Barker wrote: > nice, idea, but > > libX11.so.6 > libXext.so.6 > libXrender.so.1 > libGL.so.1 > > These are all X11, yes? pretty much any workstation will have these, but in > general, servers won't. > >

Re: [Distutils] draft PEP: manylinux1

On Thu, Jan 21, 2016 at 12:18 PM, Matthias Klose wrote: > On 21.01.2016 04:55, Nathaniel Smith wrote: > > the choice of compiler is questionable. Just a pick into a release series. > Not even the last released version on this release series. Is this a good > choice? Maybe for

  1   2   >