Dag Sverre Seljebotn | 18 Aug 14:45

[Cython] Request for review: runtests.py and NumPy issues

As we're so close to a release I'm going to post a patch here instead of 
commiting it straight away.

The patch fixes an issue with runtests.py with a lot of releases of 
NumPy. The latest svn version doesn't have the problem but the one 
shipped with the latest Ubuntu does, so I expect a lot of users may 
encounter it. The problem is that NumPy doesn't like 
distutils.unixccompiler being imported already.

One could think that the test environment should be further "sandboxed" 
and that all modules should be removed, but I don't know anything about 
sys.modules really so I'll leave that to somebody else.

Something else: The "cimport" triggers a module import so the numpy 
testcase fails on systems where numpy is not installed. This isn't all 
that serious I feel (a failing numpy testcase will communicate the right 
thing to users not having numpy installed) so I think we should wait 
until after the release (and then add some kind of "_USES" special 
testcase variable).

--

-- 
Dag Sverre
As we're so close to a release I'm going to post a patch here instead of 
commiting it straight away.

The patch fixes an issue with runtests.py with a lot of releases of 
NumPy. The latest svn version doesn't have the problem but the one 
(Continue reading)

Stefan Behnel | 18 Aug 15:56

Re: [Cython] Request for review: runtests.py and NumPy issues

Dag Sverre Seljebotn wrote:
> Something else: The "cimport" triggers a module import so the numpy
> testcase fails on systems where numpy is not installed. This isn't all
> that serious I feel (a failing numpy testcase will communicate the right
> thing to users not having numpy installed) so I think we should wait
> until after the release (and then add some kind of "_USES" special
> testcase variable).

Can't we keep a mapping of required imports (i.e. package names) to test
case name patterns in runtests.py, and then try-except on the import
before considering a matching test(s) for inclusion? That way, we could
skip the tests that have unsatisfied external requirements entirely.

If we additionally used a standard naming pattern like "numpy_xyz.pyx" for
numpy related test cases, that would become trivial to handle.

Stefan

Stefan Behnel | 18 Aug 17:10

Re: [Cython] Request for review: runtests.py and NumPy issues

Dag Sverre Seljebotn wrote:
> The problem is that NumPy doesn't like
> distutils.unixccompiler being imported already.

Could you elaborate on this a little? Which part of NumPy doesn't "like"
the module being imported? Why isn't it enough to import NumPy first (and
maybe do some stuff with it) and /then/ run the tests? To check if NumPy
is installed (i.e. to see if you can run the test), you'll have to import
it anyway.

Stefan

Dag Sverre Seljebotn | 18 Aug 18:22

Re: [Cython] Request for review: runtests.py and NumPy issues

Stefan Behnel wrote:
> Dag Sverre Seljebotn wrote:
>> The problem is that NumPy doesn't like
>> distutils.unixccompiler being imported already.
> 
> Could you elaborate on this a little? Which part of NumPy doesn't "like"
> the module being imported? Why isn't it enough to import NumPy first (and
> maybe do some stuff with it) and /then/ run the tests? To check if NumPy
> is installed (i.e. to see if you can run the test), you'll have to import
> it anyway.
> 

Actually, you are right -- this problem now disappear because numpy is 
imported before distutils (after implementing your previous proposal).

The point is the ordering of the imports:

Py> import numpy

is ok, however:

Py> import distutils.unixccompiler
Py> import numpy
Traceback (most recent call last):
    ...

Again, this is a bug in NumPy, but I like working around it and not 
requiring bleeding edge for our testcase to run (in fact it should be 
able to run in order to check how we do for older releases as well).

(Continue reading)

Stefan Behnel | 18 Aug 21:06

Re: [Cython] Request for review: runtests.py and NumPy issues

Hi,

Dag Sverre Seljebotn wrote:
> Again, this is a bug in NumPy, but I like working around it and not 
> requiring bleeding edge for our testcase to run

+1

> It commited it right away to -devel as it is an isolated change

Thanks.

Stefan


Gmane