[RFC] Requiring python 2.6

Currently lit on windows will not work with python 3 because the
internal shell has code like

except OSError, e:

and in python 3 one has to use

except OSError as e:

But that only works on python 2.6 and newer.

So the question is: any objections to dropping support for python 2.5?
Python 2.6 was released 01-Oct-2008, so it should be available
everywhere.

Cheers,
Rafael

Adding Daniel.

+1

I guess the only question is “who is using < 2.6 ?”

– Sean Silva

I’m all for… Trying to require 2.7 if possible? :slight_smile: Since we’re bumping the req, we might as well bump as far as we can.
That way we can also remove some compatibility things from (at least) lldb. (I haven’t even tried 2.6 in a while, so it might not work due to other changes)

Filipe

RHEL 6 and variants (CentOS) ship with Python 2.4. RHEL 6 is in extended support for a few more years.

I believe I’ve previously proposed a 2.7 migration on this list. A lot of people came out of the woodwork to object.

Good luck moving forward. The world is better if Python <2.7 can be dropped.

RHEL 6 and variants (CentOS) ship with Python 2.4. RHEL 6 is in extended
support for a few more years.

Right, but we don't support 2.4 today, we use features only available in
2.5+.

I believe I've previously proposed a 2.7 migration on this list. A lot of
people came out of the woodwork to object.

AFAICT, RHEL 7 includes python 2.7.5

+1

My view on this is that lit is a testing tool. If someone is competent
enough to build LLVM and run the tests then they're probably competent
enough to build a newer version of Python if for some reason they
can't obtain pre-built version.

I use lit outside of LLVM for several projects but I always use Python

= 2.7 so it's not a problem for me.

I'd also be in favour of bumping the required version higher and require 2.7

So far two bots have complained about 2.7 (but have 2.6):

http://bb.pgr.jp/builders/clang-i686-cygwin-RA-centos6/builds/12836/steps/configure/logs/stdio
http://lab.llvm.org:8011/builders/llvm-s390x-linux1/builds/12002/steps/configure/logs/stdio

Should we just upgrade those bots or reduce the requirement to 2.6?

The bot runs on a SLES 11 machine, which has Python 2.6.9.

I guess I could install an private version, but on the other hand,
SLES 11 is still in wide-spread use (we use it e.g. on one of the
main servers used for Power LLVM development ...).

Bye,
Ulrich

The bot runs on a SLES 11 machine, which has Python 2.6.9.

I guess I could install an private version, but on the other hand,
SLES 11 is still in wide-spread use (we use it e.g. on one of the
main servers used for Power LLVM development ...).

So, I think Dan Liew's point is very relevant in here. This is a
testing tool. It is a reasonable expectation that anyone wanting to
develop llvm should be able to install python 2.7, no?

Cheers,
Rafael

Well, on the other hand it would be good to avoid unnecessary hurdles
for casual users to start getting involved in LLVM development, maybe
even only simply to run the test suite (e.g. to help track down an
issue occurring only a machine the main developers don't have ready
access to).

However, I'm no Python expert and don't fully understand what benefits
the availability of version 2.7 brings over 2.6. In the end it's a
judgement call, which I don't have a firm opinion on ...

Bye,
Ulrich

Well, on the other hand it would be good to avoid unnecessary hurdles
for casual users to start getting involved in LLVM development, maybe
even only simply to run the test suite (e.g. to help track down an
issue occurring only a machine the main developers don't have ready
access to).

Well there is an alternative. ``lit`` is available as a stand-alone
application via pypi at [1]
so what we could do is upgrade lit in the SVN repo to only support
Python >= 2.7 and note somewhere in the docs that
to use the old lit that works with python 2.6 they can do

$ pip install lit==0.4.1
$ lit -vs test/

This may eventually break if lit changes too much in SVN.

However, I'm no Python expert and don't fully understand what benefits
the availability of version 2.7 brings over 2.6. In the end it's a
judgement call, which I don't have a firm opinion on ...

There's a list here [2].

[1] https://pypi.python.org/pypi/lit
[2] https://docs.python.org/2.7/whatsnew/2.7.html

Thanks,
Dan.

So far two bots have complained about 2.7 (but have 2.6):

http://bb.pgr.jp/builders/clang-i686-cygwin-RA-centos6/builds/12836/steps/configure/logs/stdio

http://lab.llvm.org:8011/builders/llvm-s390x-linux1/builds/12002/steps/configure/logs/stdio

Should we just upgrade those bots or reduce the requirement to 2.6?

2.6 + py3k is a generally good combination for typical code and is easy to
maintain. It is not possible to be both 2.5 and py3k compatible without
huge hurdles.

-- Sean Silva

Well, I am no Python expert either. I went with 2.7 because it was suggested and 4 years old software sounded old enough.

If there are no objections I will downgrade the requirement back to 2.6 on Sunday (when I will be back at my computer).

Hi,

Well, I am no Python expert either. I went with 2.7 because it was suggested
and 4 years old software sounded old enough.

python 2.7 will be maintaned until 2020
(https://hg.python.org/peps/rev/76d43e52d978) so please leave it
as-is. People should be updating.

I would also encourage making Python 2.7 the minimum. Distributions
that move at glacial speed like RHEL6, CentOS6 and SLES11 can't even
build LLVM out of the box due their out of date versions of gcc (4.4 I
think) so I'm not convinced that arguments about avoiding "unnecessary
hurdles for casual users to start getting involved in LLVM
development" apply for these distributions. Anyone building LLVM on
these platforms can only do so by investing effort into upgrading
their C++ compiler. If they are willing to upgrade their compiler then
I see no reason why they would resist installing a newer version of
Python as well.

And to add to this,

gcc for Debian wheezy and Ubuntu 12.04 is too old to build LLVM >= 3.3

However, both of those platforms have Python 2.7.x as the standard install.

Python will not be your limiting factor here.

Just a reminder, these bots are still not operational because of this change.

Well, there were valid objections to lowering the requirement.

If we can require the host compiler to be upgraded, it is probably ok
to require python to be upgraded too, no?

Cheers,
Rafael

I agree. But perhaps a gentler way to do this would be to downgrade to
Python 2.6 in trunk for now and agree a timeline for the owners of the
currently broken bots (I've CC'ed the ones Rafael mentioned) to
upgrade (e.g. a week), unless they know they can get the upgrade done
quickly. Thoughts?