Dropping support for Python 2.4 and 2.5 / supporting Python 3

[David Champion]

* On 14 May 2014, Gregory Szorc wrote: 
> On Wed, May 14, 2014 at 9:41 AM, David Champion <dgc at uchicago.edu> wrote:
> 
> > * On 13 May 2014, Gregory Szorc wrote:
> > >
> > > While continuing to support Python 2.4 for RHEL 5 is a noble goal, I
> > > think it is one that should be abandoned ASAP. 2.4 and 2.5 (AFAICT
> >
> > I don't think you can have both of these. Either it's noble or it should
> > be abandoned. :)
> >
> > > Is dropping support for 2.4, 2.5, and even 2.6 annoying for RHEL, etc
> > > users? Yes. But I don't think it will be too bad in the wild. There
> > > are tons of Python 2.7 RPMs and debs in existence. StackOverflow has
> > > answers abound on how to configure them. Compiling and installing
> >
> > I understand why you would want to drop 2.4.  I don't like it either.
> > But the reasons go beyond annoyance -- it's right to the heart of
> > whether you want to support a platform (RHEL 5, Centos 5, SL 5) that
> > remains and will remain for some time yet.  I can't answer that for
> > you or for the dev team, but I can address why this is more than just
> > annoying.
> >
> > For individual users, yes, the options you present exist and are
> > reasonable.  But at the site management scale, or worse, when dealing
> > across multiple sites, it's simply fallacious to assume that any site
> > has these options.  There are thousands of installations that do not
> > have this choice.  Some sites are legally regulated and cannot install
> > additional, potentially-conflicting software beyond the base until
> > a recertification window occurs.  Other sites are regulated by the
> > business, which is less imposing but not necessarily less of a brick
> > wall.  You can put a burden on site admins if it's a self-imposed
> > constraint, but legal consequences are harder to work around.
> >
> > I currently work in research computing; we try to deploy workloads on
> > servers across the grid, and we simply can't count on the existence
> > of any python except what comes with the base OS.  Installing other
> > distributions is not up to us.  While many sites have moved on to RHEL6
> > bases, Factoring out RHEL5-based distributions still eliminates around
> > 30%-40% of compute nodes.  (Perhaps workloads should not depend on
> > version control software; there's merit to this view. But I'm trying to
> > illustrate a class of problems with a single example.)
> >
> >
> > I'm not really advocating against what you propose -- it's not mine
> > to decide.  I understand the value of making the decision you're
> > suggesting, and I trust that you have more authority in it than I
> > do.  But I do think it exactly equates to whether Mercurial wants to
> > honor these still-supported distributions, and I think that proposing
> > workarounds as solutions ignores all but the simplest of management
> > scenarios (single system/single admin).  I think that the workarounds
> > you mentioned, therefore, aren't part of the discussion, and the
> > proposal is a lot simpler (if perhaps less appealing) than you made it.
> 
> 
> I understand installing a more modern Python is work that many would like
> to see avoided.

My point is that in many situations, it's not inconvenient -- it's near
impossible.

> The question I would like to see answered is "is staying on Mercurial 3.0
> acceptable?" If we drop Python 2.4 and 2.5, you'll still have Mercurial 3.0
> (or maybe even 3.1, 3.2, whatever). Is that not good enough?

Fair point -- perhaps so, I'd want to see others address that.
Mercurial's backward compatibility is very good.  This may make any
objection moot.

> If upgrading packages on these clusters is so difficult, how are you
> managing Mercurial?

Python is core, and used by a wide variety of other tools. Mercurial is
user-facing only.  It's not difficult to install or upgrade a package;
the problem is that you're adding or replacing with a package that
could (by some standard of concern) conflict with a package that other
critical code is using.  We're not talking about system admins who have
a hard time with system administration, we're talking about system
admins with significant legal, cultural, or physical constraints on what
they can do.

> If www.python.org (or some other entity) hosted binary Python 2.7 archives
> that could be very easily installed and ran, would that make things easier?

No, for reasons articulated.

-- 
       David Champion • dgc at uchicago.edu • University of Chicago
Enrico Fermi Institute • Computation Institute • USATLAS Midwest Tier 2
                      OSG Connect • CI Connect