Dropping support for Python 2.4 and 2.5 / supporting Python 3

[Sean Farley]

Augie Fackler <lists at durin42.com> writes:

> On Wed, May 14, 2014 at 11:57 AM, Arne Babenhauserheide <arne_bab at web.de>wrote:
>
>> Am Dienstag, 13. Mai 2014, 16:31:12 schrieb Gregory Szorc:
>> > I believe Mercurial should look
>> > forward and drop support for at least 2.4 and 2.5 ASAP.
>>
>> If this had already be done, I would have had a much harder time to
>> install a local up-to-date Mercurial on one of our universities clusters.
>> Backwards compatibility might sound like wasted time if you’re on a
>> fast-moving platform, but it’s essential for quite a few users.
>>
>
> Is there no available binary of 2.6 or 2.7 for your platform that could be
> installed alongside the system Python? You're talking about using a Python
> so old it hasn't gotten security patches in over 5 years - there's a lot of
> important things that have happened since then.

The problem is that most clusters (at least for Rocks) reinstall
themselves upon reboot. So, if you want to provide custom software, you
have be go through a huge hassle of creating a custom iso. And if you're
not the admin, then you have to build python in your home directory
... which is on NFS, so you know, that's really convenient.

Sometimes, you can't even build your own python because you're on an
esoteric system (IBM's BlueGene, for example, or AIX). The vendor
sometimes provides a custom built python but they aren't required to
tell you how they built it.

These clusters are built to never to be changed, basically. Things like
security patches don't really matter to the administration since, as
they'll tell you, there are only trusted users (usually only accessible
via an internal network). I'm not saying I agree with this excuse, I'm
just saying that the status quo is: don't change.

Summary: it is a *royal* pain in the ass to install custom python on a
cluster; sometimes even close to impossible.