-----Original Message-----
From: Alex Walters [mailto:tritium-l...@sdamon.com] 
Sent: Wednesday, February 7, 2018 12:21 AM
To: 'Janzert' <janz...@janzert.com>
Subject: RE: [Distutils] draft PEP: manylinux2

> -----Original Message-----
> From: Distutils-SIG [mailto:distutils-sig-bounces+tritium-
> list=sdamon....@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

Distutils-SIG maillist  -  Distutils-SIG@python.org

Reply via email to