Dropping support for Python 2.4 and 2.5 / supporting Python 3

[David Champion]

* 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.

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