[Nipy-devel] python *2.4* deps

[Tim Leslie]

On 3/4/07, Jarrod Millman <millman@berkeley.edu> wrote:
> On 3/2/07, Benjamin Thyreau <benjamin@decideur.info> wrote:
> > There are some hard-coded python2.4 references, for example in the ./test
> > script first line. Is there a legitimate reason for not having simply
> > "/usr/bin/env python" ? Our runtime environment here is mostly focused on
> > python2.5 and most distribution will do the same soon, so if nobody asks
> > otherwise and nothing break, i'd like to drop those refs.
>
> Hey Benjamin,
>
> I think that the hard-coded reference to python2.4 was added almost a
> year ago because we were using features added in 2.4, which weren't
> available in 2.3.  I can't remember what features we were using; but I
> know that we use decorators at least.  So we requiring python >= 2.4.
>
> The problem is that Debian stable, I believe, is still using python
> 2.3 as the default.  So the change you made is going to break test for
> Debian users.  Since Debian is so conservative in terms of upgrading
> packages, this is a long-standing problem for Debian.  They were
> discussing how to deal with it back in the python 1.5 to 2.0 days:
> http://groups.google.com/group/debian.python/browse_thread/thread/12fbd795fd731de6?hl=en&seekm=87itdf28b3.fsf%40marant.org#link1
> I think the Debian developers actual recommend against using env and
> recommend expliciting stating which version of python you want (eg,
> /usr/bin/python2.4).  That doesn't help us since we are interested in
> using python >= 2.4.
>
> We could use disutils to take care of figuring out what version of
> python to use, but that doesn't help if you are running nipy from your
> svn working directory.  Unfortunately, there isn't a clean solution to
> this problem.
>
> My suggestion would be for us to only run NIPY scripts that have been
> installed and let distutils handle version rules.  Also we may want to
> get rid of the test script.  Now that we are using NumpyTest, we
> should run the tests interactively:
>   import neuroimaging as nipy
>   nipy.test()
> I think this is probably a good idea anyway, since it would be more
> similar to the way you test numpy and scipy.
>

The idea to get rid of the ./test script is a good one I think. Now
that the NumpyTest stuff is working we should move towards using only
it. There are two outstanding issues which need to be addressed before
getting rid of the ./test script.

The first is the use of the decorator flags such as --data, --slow,
etc, which allow us to run certain subsets of the tests. As of a
couple of hours ago these can be accessed by doing things like
nipy.test(flags="--all"), nipy.test(flags=["--data", "--slow"], etc.
There is room for improvement in the underlying mechanism, but for the
time being this works.

The other issue is how to run the doctests which we have. We are
looking into using Fernandos package which helps integrate doctests
and make them more practical. This is discussed in another thread.

Once these two issues are resolved I see no reason to keep the test
script around.

Cheers,

Tim

> Just out of curiosity, were you getting any errors running test using
> python2.4?  Does anyone think we should keep test rather than trying
> to replicate its functionality in the python shell?  If so, do you
> have any suggestions how we could fix the she-bang to use python2.4
> over 2.3, while also prefering 2.5 over 2.4?
>
> Thanks,
>
> --
> Jarrod Millman
> Computational Infrastructure for Research Labs
> 10 Giannini Hall, UC Berkeley
> phone: 510.643.4014
> http://cirl.berkeley.edu/
> _______________________________________________
> Nipy-devel mailing list
> Nipy-devel@neuroimaging.scipy.org
> http://lists.neuroimaging.scipy.org/mailman/listinfo/nipy-devel
>