[SciPy-dev] tests, relative import: what's best ?

[David Cournapeau]

Robert Kern wrote:
> David Cournapeau wrote:
>> Hi,
>>
>>     I have a question regarding tests and import in numpy/scipy in 
>> general. When implementing tests, the package to be tested has to be 
>> imported, and there are two possibilities on how to do it (both are used 
>> in scipy). Taking an hypothetical package foo in scipy as an example:
>>
>>     1 : using set_package_path /restore_path facilities of 
>> numpy.testing, and do a "relative" import
>>
>> set_package_path()
>> from foo import bar
>> restore_path()
>>
>> This means that you can test the package foo without building the whole 
>> scipy source tree. This is for example used in scipy.linalg tests. It 
>> also correspond to DISTUTILS.txt doc in numpy/doc.
>>
>>     2 : using set_package_path / restore_path facilities, and do a 
>> "absolute" import:
>>
>> set_package_path()
>> from scipy.foo import bar
>> restore_path()
>>
>> In this case, I don't understand why set_package_path is used ? And 
>> also, this means that you cannot test the subpackage by itself, you need 
>> to install the whole scipy tree. This is for example used in 
>> scipy.signal tests.
>>
>> Are there any advantages to 2 ? If not, would it be a good idea to 
>> convert every package to convention 1 ?
>
> If we can, I'd prefer that we simply make build_src/build_ext --inplace work for
> numpy and scipy and then remove set_package_path() and restore_path().
I didn't know about this option of distutils. I've just tried it on some 
packages, it seems to just put the extensions and python files outside 
the usual build directory ? This way, we should follow the first method, 
but without messing sys.path ?

What does not work with numpy/scipy related to --inplace ?

David