Dropping support for Python 2.4 and 2.5 / supporting Python 3

[Gregory Szorc]

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.

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?

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

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20140514/312e6684/attachment.html>