Re: [Distutils] draft PEP: manylinux2
-----Original Message-----
From: Alex Walters [mailto:tritium-list@sdamon.com]
Sent: Wednesday, February 7, 2018 12:21 AM
To: 'Janzert'
-----Original Message----- From: Distutils-SIG [mailto:distutils-sig-bounces+tritium- list=sdamon.com@python.org] On Behalf Of Janzert Sent: Tuesday, February 6, 2018 3:33 PM To: Distutils-Sig@Python.Org Subject: Re: [Distutils] draft PEP: manylinux2
On 2/5/2018 16:01, Nick Coghlan wrote:
Compare:
- manylinux1 vs manylinux2 vs manylinux3 - manylinux2007 vs manylinux2010 vs manylinux2014
I'll leave this just as a data point (anecdote) from someone that isn't heavily involved with linux sysadmin or python packaging. Feel free to make of it what you like. I generally run debian stable and occasionally ubuntu lts on servers and the latest ubuntu for my workstation.
If I were looking to install a package and one of the binaries available is manylinux2010 I probably completely pass over that option and don't even attempt using it. My assumption would be anything that old probably isn't going to work on my 2016 or newer OS. Whereas manylinux(1, 2, 3) I would think has a good chance of working on any reasonably modern linux.
If not for having read the discussion here I would have interpreted a date, especially a date that's the better part of a decade in the past, completely the wrong way.
Having said that, I'm pretty sure that pip should in general be handling this decision for me and doing the right thing anyway? So it probably doesn't matter too much.
Janzert
This is a really good point. Since pip is the main interface to packages for end users anyways, we can call it manylinux8675309 and it wouldn't really matter to users - the name only really matters to package maintainers, not users. And because of that, manylinux2010, manylinux2014, etc makes more sense. A package maintainer is expected to be more educated about these matters, and that naming scheme is more useful to them. "Whats the oldest linux system my code will run on?" is a very likely question a maintainer would have when building binary packages, and the year-based naming scheme is the logical answer. +1 to manylinux2010, -0 manylinux2
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On 7 February 2018 at 15:21, Alex Walters
This is a really good point. Since pip is the main interface to packages for end users anyways, we can call it manylinux8675309 and it wouldn't really matter to users - the name only really matters to package maintainers, not users. And because of that, manylinux2010, manylinux2014, etc makes more sense. A package maintainer is expected to be more educated about these matters, and that naming scheme is more useful to them. "Whats the oldest linux system my code will run on?" is a very likely question a maintainer would have when building binary packages, and the year-based naming scheme is the logical answer.
Exactly :) Knowing the baseline year gives publishers a clear set of "almost certainly won't work" environments: anything released prior to the baseline year (since the library versions included in the baseline either won't have existed yet, or may not have been broadly adopted). This is mostly likely to become important if we end up defining a newer platform variant for the sake of ppc64le and aarch64: targeting a compatibility baseline like "manylinux2017" would make it clear that it excludes things like Ubuntu 16.04 and RHEL/CentOS 7.0 (even if it ends up including a later RHEL/CentOS 7.x point release, or the mid-LTS opt-in platform upgrades that Canonical publishes) in a way that manylinuxN doesn't. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 07/02/2018 05:21, Alex Walters wrote:
...........
This is a really good point. Since pip is the main interface to packages for end users anyways, we can call it manylinux8675309 and it wouldn't really matter to users - the name only really matters to package maintainers, not users. And because of that, manylinux2010, manylinux2014, etc makes more sense. A package maintainer is expected to be more educated about these matters, and that naming scheme is more useful to them. "Whats the oldest linux system my code will run on?" is a very likely question a ........ I dispute the fact that package maintainers should be more educated about these matters. The package maintainer usually knows about one or a few packages (in my case reportlab etc). I know very little about the architectures and platforms that people are using with reportlab today. Nor do I know (or need to know) about multiple linux distributions and what libraries they supported and in what year.
I do agree that the name of the available packages shouldn't really matter. Provided there is information in the name that allows the requesting pip to decide on the appropriate package to use (or lack thereof) that should suffice. Is pip clever enough to decide this or will we have to rely on the mysterious _manylinux module? -- Robin Becker
On 7 February 2018 at 19:58, Robin Becker
On 07/02/2018 05:21, Alex Walters wrote:
This is a really good point. Since pip is the main interface to packages for end users anyways, we can call it manylinux8675309 and it wouldn't really matter to users - the name only really matters to package maintainers, not users. And because of that, manylinux2010, manylinux2014, etc makes more sense. A package maintainer is expected to be more educated about these matters, and that naming scheme is more useful to them. "Whats the oldest linux system my code will run on?" is a very likely question a
........ I dispute the fact that package maintainers should be more educated about these matters. The package maintainer usually knows about one or a few packages (in my case reportlab etc). I know very little about the architectures and platforms that people are using with reportlab today. Nor do I know (or need to know) about multiple linux distributions and what libraries they supported and in what year.
Aye, there will still be guidance on packaging.python.org for folks that just want an opinionated recommendation on what binary platforms are best to target when producing wheel files. For that scenario, whether we call it "manylinux2" or "manylinux2010" shouldn't matter too much (since folks will just be copying it from the recommendation, or using a helper tool like cibuildwheel).
I do agree that the name of the available packages shouldn't really matter. Provided there is information in the name that allows the requesting pip to decide on the appropriate package to use (or lack thereof) that should suffice. Is pip clever enough to decide this or will we have to rely on the mysterious _manylinux module?
Hmm, that question prompted me to notice a flaw in the current wording of https://www.python.org/dev/peps/pep-0571/#platform-detection-for-installers. The way that's currently worded suggests that "bool(_manylinux.manylinux2010_compatible)" would be the only way to identify whether or not a manylinux2010 wheel should be considered for installation. That isn't the case: installers checking for manylinux2010 compatibility should fall back to "have_compatible_glibc(2, 12)" if there's no `_manylinux` module, or if that module doesn't include a "_manylinux.manylinux2010_compatible" attribute. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Wed, Feb 07, 2018 at 08:41:06PM +1000, Nick Coghlan wrote:
Hmm, that question prompted me to notice a flaw in the current wording of https://www.python.org/dev/peps/pep-0571/#platform-detection-for-installers.
The way that's currently worded suggests that "bool(_manylinux.manylinux2010_compatible)" would be the only way to identify whether or not a manylinux2010 wheel should be considered for installation.
That isn't the case: installers checking for manylinux2010 compatibility should fall back to "have_compatible_glibc(2, 12)" if there's no `_manylinux` module, or if that module doesn't include a "_manylinux.manylinux2010_compatible" attribute.
Agh, thank you! Fortunately that's exactly what the draft pip implementation does: https://github.com/pypa/pip/pull/5008/files#diff-542f0dc2284dcb0cb6a0382dfee... I've pushed a new branch that includes this change: https://github.com/markrwilliams/peps/commit/4476f9c77b5adb6df4dcc00829303a5... -- Mark Williams mrw@twistedmatrix.com
participants (4)
-
Alex Walters
-
Mark Williams
-
Nick Coghlan
-
Robin Becker