seeking advice - make check for python bindings not useful

[Mark Jenkins]

This might come as a surprise, but I've never actually looked at the 
python bindings test suite, (src/optional/python-bindings/tests); my 
colleague worked on it.

 From what I'm looking at, it isn't useful and make check with 
--enable-python-bindings should actually fail under many circumstances.

(My understanding is that there isn't currently a problem with make 
check/distcheck when --enable-python-bindings isn't present; my thanks 
go out to the folks who fixed that in April)

The gnucash libraries have to be findable when the gnucash_core_c.so 
module is loaded. I use gnucash-evn to achieve this when running my 
python programs that use the bindings.

The test suite does likewise, it invokes 
$(top_builddir)/src/bin/gnucash-env via TESTS_ENVIRONMENT for the test. 
This is wrong, unless make install has been called first (not required 
for make check), executing (top_builddir)/src/bin/gnucash-env is 
useless, it results in:
"""exec: 8: gnucash-env: not found"""
because that gnucash-env script is designed to execute the second stage 
gnucash-env that is found in the installation, or anywhere else in PATH, 
but not in the source/build directories.

So the current use of gnucash-env in python-bindings/tests/Makefile.am 
is wrong.

Python also needs to be able to find the gnucash python modules when 
they are imported. Python will look for modules in pre-defined 
directories, and ones listed in PYTHONPATH.

The test suite sets PYTHONPATH via TESTS_ENVIRONMENT as well, and it 
sets it to $(pythondir). This is again wrong, $(pythondir) is the place 
where the modules go after installation. This means that make check can 
only succeed if make install occurs first, or the gnucash modules have 
already been installed somewhere else in the default PYTHONPATH, which 
is again wrong.

The situation is complicated further by the fact that the .py and .so 
files that are eventually installed together into $(pythondir)/$PACKAGE 
($PACKAGE is gnucash) are still in separate places after make, the 
python files are in src/optional/python-bindings, and the .so files end 
up wherever the autotools put them, in my case 
src/optiona/python-bindings/.libs/ .

So, I'd like advise from the list on how to proceed.

Here are some options:

1) make installcheck
Instead of performing the tests during make check, perform them during 
make installcheck which will allow for the tests to be performed after 
installation and to use the installed gnucash-env and install gnucash 
module directory
See
http://sources.redhat.com/automake/automake.html#Install-Tests

I'm not sure which version of automake this requires and what version 
GnuCash is requiring.

2) simpler tests
Figure out a way to construct an environment for the tests like 
gnucash-env provides, only with the location of the libraries within the 
source directory. Also, set PYTHONPATH to include both the location of 
the .py and .so files.

With an environment like that, you could re-write the tests to not do:
python> from gnucash import Session

and to instead:
python> from gnucash_core import Session

3) same tests, better environment
Do the same with gnucash library search stuff as from 2) . Contract a 
$PACKAGE (gnucash) directory that contains/link both the .py and .so 
files. Set PYTHONPATH to include this directory.

With that option you could leave the tests alone -- they would still 
"from gnucash import Session", which makes the test files more useful, 
they can also double as documentation on how to use the bindings 
post-install.

4) Give up
Remove the tests entirely and just ship python-bindings/example_scripts 
for people to try out after installation.


So, your thoughts? 1, 2, 3, 4, or something I haven't thought of?


Mark Jenkins
Member
ParIT Worker Co-operative

cc Scott
cc fellow ParITistas