Dropping support for Python 2.4 and 2.5 / supporting Python 3

[David Champion]

* On 14 May 2014, Gregory Szorc wrote: 
> On 5/14/2014 10:41 AM, David Champion wrote:
> > * 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.
> 
> Just to be clear, are you aware that you can decompress a prebuilt
> Python 2.7 archive into say ~/python and run it with ~/python/bin/python
> without any conflicts with your system Python? i.e. a Python
> installation could be made user facing in much the same way as Mercurial
> is. This would not require system administrator cooperation.

Yes.

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