Travis-CI stopped supporting Python 3.1, but added 3.3
Hi, I noticed that the 3.1 tests are now failing. After clarification with the Travis guys: https://groups.google.com/d/topic/travis-ci/02iRu6kmwY8/discussion I've submitted a fix to our .travis.yml (and backported to 1.7): https://github.com/numpy/numpy/pull/2850 https://github.com/numpy/numpy/pull/2851 In case you were wondering. Do we need to support Python 3.1? We could in principle test 3.1 just like we test 2.4. I don't know if it is worth the pain. Ondrej
On Fri, Dec 21, 2012 at 2:23 AM, Ondřej Čertík <ondrej.certik@gmail.com>wrote:
Hi,
I noticed that the 3.1 tests are now failing. After clarification with the Travis guys:
https://groups.google.com/d/topic/travis-ci/02iRu6kmwY8/discussion
I've submitted a fix to our .travis.yml (and backported to 1.7):
https://github.com/numpy/numpy/pull/2850 https://github.com/numpy/numpy/pull/2851
In case you were wondering. Do we need to support Python 3.1? We could in principle test 3.1 just like we test 2.4. I don't know if it is worth the pain.
I think for 1.7.x we should. Ralf
On Fri, Dec 21, 2012 at 1:23 AM, Ondřej Čertík <ondrej.certik@gmail.com> wrote:
Hi,
I noticed that the 3.1 tests are now failing. After clarification with the Travis guys:
https://groups.google.com/d/topic/travis-ci/02iRu6kmwY8/discussion
I've submitted a fix to our .travis.yml (and backported to 1.7):
https://github.com/numpy/numpy/pull/2850 https://github.com/numpy/numpy/pull/2851
In case you were wondering. Do we need to support Python 3.1? We could in principle test 3.1 just like we test 2.4. I don't know if it is worth the pain.
It probably isn't much pain, since Python is easy to compile, and I don't think we've been running into many cases where supporting 3.1 required workarounds yet? (As compared to 2.4, where we get compatibility-breaking patches constantly.) It's a crude metric and I'm not sure what conclusion it suggests, but we have download stats for the different python-version-specific pre-built numpy binaries: http://sourceforge.net/projects/numpy/files/NumPy/1.6.1/ http://pypi.python.org/pypi/numpy/1.6.1 http://sourceforge.net/projects/numpy/files/NumPy/1.6.2/ http://pypi.python.org/pypi/numpy/1.6.2 It looks like python 2.5 is several times more popular than 3.1, and its popularity is dropping quickly. (30% fewer downloads so far for 1.6.2 than 1.6.1, even though 1.6.2 has more downloads overall.) -n
On Fri, Dec 21, 2012 at 12:05 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Dec 21, 2012 at 1:23 AM, Ondřej Čertík <ondrej.certik@gmail.com> wrote:
Hi,
I noticed that the 3.1 tests are now failing. After clarification with the Travis guys:
https://groups.google.com/d/topic/travis-ci/02iRu6kmwY8/discussion
I've submitted a fix to our .travis.yml (and backported to 1.7):
https://github.com/numpy/numpy/pull/2850 https://github.com/numpy/numpy/pull/2851
In case you were wondering. Do we need to support Python 3.1? We could in principle test 3.1 just like we test 2.4. I don't know if it is worth the pain.
It probably isn't much pain, since Python is easy to compile, and I don't think we've been running into many cases where supporting 3.1 required workarounds yet? (As compared to 2.4, where we get compatibility-breaking patches constantly.)
Yes, I was going to suggest that it really is not a big deal to support 3.1, as far as I see it by my experience with Travis tests on numpy PRs in the last half a year. We can compile it like we do for 2.4, or we can even provide a prebuild binary and just install it in the Travis VM each time. So I'll try to provide a PR which implements testing of 3.1, unless someone beats me to it. Ondrej
participants (3)
-
Nathaniel Smith -
Ondřej Čertík -
Ralf Gommers