Building gnucash 2.6.0 python bindings on Debian

[Geert Janssens]

Hi Bas,

On Wednesday 15 January 2014 21:08:34 Bas ten Berge wrote:
> Hi,
> 
> I'm a new user to gnucash version 2.6, using a postgresql backend and
> I'm impressed with it. I used to build invoices using Word and I now
> intend to use gnucash for accounting. The installed templates don't
> work for me, so I decided to start building a web interface when I
> learned about python-gnucash. This web interface should allow me to
> use templates I'm experienced with to construct an invoice. That's
> the basic idea.
> 
Tom Lofts contributed an initial REST api to the python bindings which may be useful for your 
situation.

> I've got the gnucash GUI running on multiple Windows machines, the
> postgresql database on a single NAS and I intend to run the web
> interface on a raspberry pi. I was not able to install pre-build
> python-gnucash packages, as these are build for version 2.4 and there
> were version mismatch errors when I used version bindings version 2.4
> on a database build with gnucash 2.6.

You probably know already but I'll repeat the mantra anyway: don't be tempted to open you 
database simultaneously with multiple users. You will have to time-share your access one user 
at the time. Ignoring this will at best leave one user with outdated information or in the worst 
case data loss.

I'm thinking particularly at your webserver user. Here are some design considerations:
- you can't have the webapi keep the GnuCash book open all the time. GnuCash loads all data 
into memory at startup and only looks at that data until it's closed again. So if the web user 
opens the book permanently, it will see outdated information as soon as another user on a 
Windows machine changes anything. (GnuCash writes each change immediately through to the 
database but assuming your web-api will access the file read-only, that's not relevant here)
- so given you should open the GnuCash book each time the web-server needs access to it the 
size of your book may at some point become a bottleneck. As I just mentioned GnuCash reads 
the whole book into memory when it's opened. So that would mean that the whole book is read 
for each web access you do. For a small book that's not too important. But I have a book for 
example with 10 years of history which takes about half a minute to open via the python 
bindings. Doing that for each web-access may be a slow solution.
> 
> I build the gnucash python bindings using configure --enable-python
> --disable-gui --enable-locale-specific-tax, make, make install.
> Importing the gnucash bindings fail after installation. There's a
> message mentioning the schema is missing:
> <GLib-GIO> Settings schema 'org.gnucash.general' is not installed
> 
> There was a question on the list about that, so the fix was easy, but
> it got me wondering when the schema files were installed, and I guess
> that happens when the gui is build, right? Could those files be
> automatically installed when the python bindings are installed, or
> any other part of the backend? This enables a developer to build an
> API distribution only for gnucash, which is exactly what I need at
> this time ;-)

The schema files are indeed installed together with the gui components. Frankly the --disable-
gui hasn't been tested in years IMO. GnuCash is primarily a desktop application and not a 
library or service.

Having said that I don't think there's a strong reason it should stay that way. The main schema 
files could easily be installed in for example the app-utils module. This module is responsible 
anyway for the GSettings backend. A couple of schemas are only installed as part of optional 
modules (like aqbanking and ofx). These can remain in their respective directories.

Can you file this as an enhancement request in bugzilla [1] ?

> 
> Since I'm posting to the list; there's a warning message when I import
> gnucash:
> ----------------------------------------------------------------------
> ---------------------------- process:1075): GLib-WARNING **: GError
> set over the top of a previous GError or uninitialized memory.
> This indicates a bug in someone's code. You must ensure an error is
> NULL before it's set.
> The overwriting error message was: No such file or directory
> ----------------------------------------------------------------------
> ---------------------------- Is there something I can do about this?
> 

You could try to figure out which error is being set first and overridden later by using a 
combination of gdb and setting G_DEBUG to fatal-warnings [2]

> For reference; there was a dbus message too:
> ----------------------------------------------------------------------
> ---------------------------- * 20:51:19  WARN <> Command line
> `dbus-launch
> --autolaunch=57ae80824714b7b337db9bbc5115ac19 --binary-syntax
> --close-stderr' exited with non-zero exit status 1: Autolaunch error:
> X11 initialization failed.\n
> ----------------------------------------------------------------------
> ---------------------------- That message is gone when dbus is started
> in shell syntax and the script is started afterwards:
> eval `dbus-launch --sh-syntax`
> 

Interesting. I didn't know dbus could be started from a shell as well. GnuCash itself can't use 
that though as it doesn't start dbus by itself (and only uses it on linux btw). dbus is started by 
gsettings.

But still this could be a good tip to add to our python binding wiki page [3] for others that wish 
to work with gnucash data via python in environments that lack a proper X.

Geert

[1] More details on our bug tracker: http://wiki.gnucash.org/wiki/Bugzilla
[2] More info on G_DEBUG flags: https://developer.gnome.org/glib/stable/glib-running.html
[3] http://wiki.gnucash.org/wiki/Python