Report wrapper to call python scripts?

Geert Janssens geert.gnucash at kobaltwit.be
Wed Dec 24 06:25:23 EST 2014


On Wednesday 24 December 2014 12:22:46 Dmitry Pavlov wrote:
> A brief search through list did not bring any results, so I decided to
> start a new one.
> 
> First of all: no offence but most gnucash reports are poorly
> implemented. It's not because they useless or looks not pretty (most
> of them are useful and good, calm down :)).

The report system is indeed in dire need of some attention.

> The reason is that a
> model (i.e. data of the report) is completely messed up with the view
> (html tags) in report generation code + html creation tag by tag is
> really outdated now, there are more proper tools like templates for
> that.
> 
Absolutely. That's why a couple of years back one developer started to rewrite the reports 
based on eguile which is a templating system written in guile.

The developer ran out of time so only a few reports have been written based on eguile: there is 
a balance sheet and a tax invoice report. And I have just recently added a payment receipt 
report based on eguile as well.

> Of course it's a really huge work to rewrite that completely in more
> model-view style or rewrite that in different language.
> 
Yes. That's one reason it hasn't happened yet.

Other reasons are that the active developers are mostly focused on the core rewrite in c++ 
making the core a moving target. That's probably not the best moment to rewrite a report 
system. The current report system - while very outdated - is rather stable and well understood. 
That makes it easier to keep working on top of a heavily changing core.

Yet another reason why I personally have been holding off of rewriting the report system (other 
than insufficient time) is that the developers intend to move towards a more sql driven data 
model. If that succeeds the report system could perhaps be replaced with one of the many 
existing sql based reporting systems.

> So I have idea: Gnucash already have an infrustructure of invoking
> scheme reports, saving settings, etc.
> What about implementing some "wrapper" report that can just invoke
> some script (for example that use python bindings).

That could be an interesting approach. However it's important to keep in mind that gnucash 
supports multiple platforms: linux, Windows and OS X. If you want to write reports intended to 
be included with gnucash and in a language other than guile that should be a language that is 
supported on all three platforms.

You mention python. While there are versions of python for all of them, there are no python 
bindings for gnucash on Windows and OS X. There have been several attempts to get it to work 
on Windows, but no success just yet. The same goes for OS X. There is no reliable way yet to 
install working python bindings on all supported versions of OS X. This is mostly due python's 
own incompatibilities between python versions.

Next if at some point the python bindings are working on all platforms, there is the distribution 
issue: if we start to depend on python for some features, we would need to ship python with our 
Windows installer. That would mean a considerable increase in size. That is only justified if the 
functionality would be greatly enhanced by this.

So as things *currently* stand python is IMO not an option (yet) to replace the reporting system. 
Sorry about that.

The only languages we have natively available on all supported platforms are c, c++, guile and 
javascript (via webkit). For guile there are bindings to many of the c libraries. For javascript 
there aren't (yet?).

> In it's settings
> we can point to specific script and all guile invocation would just
> 1. include execution of that script with passing parameters from
> options
If I understand you correctly you want to separate the options from the report generating code ? 
So your wrapper script would be responsible for displaying the options to the user and the 
actual report script only gets the values passed in ?

The way I understand the code that will already be a big work because the options for each 
report are also defined in the same report scheme file. And the whole options handling code is 
90% scheme code. The options themselves live in the guile context, not in C. Displaying the 
options dialog is about 70% guile code which expects the options to live in guile. (I happened to 
look at that code flow yesterday, that's why I know).

So making this part language agnostic means rewriting the options code. Which happens to be 
something I *am* considering if I find the time :)

> 2. grab output that is supposed to be report content (html
> for now) and include that as it's own result
> 
If I understand things correctly this second part is what is done now already. The guile reports 
generate an html output file that is then parsed by the integrated webkit engine.

> In that case we can have one more language to implement reports,
> because scheme is not so popular now, and many people find it not so
> easy to use, especially when we are talking about reporting :)
> 
As far as I know scheme is indeed not the favorite language of any of the active developers. 
GnuCash however still greatly depends on it for much of its critical code. It is on the roadmap to 
change this. That is a big work and help would be much appreciated.

The work is done bottom-up so far: first the core libraries are being revisited and rewritten in 
c++. That should give us a much better object model to work from for the higher level parts like 
the gui and reports.

> I'm not sure that I can implement all that stuff myself, but if
> someone find that idea good enough I'll be glad to discuss that and
> collaborate to implement that wrapper script.

I am open to viable alternatives. If you want to pursue the python road the first step would be 
to make sure the python bindings work reliably on Windows and OS X.

Without that the wrapper script will have to remain in the optional python bindings section of 
gnucash, greatly reducing its usefulness.

Geert


More information about the gnucash-devel mailing list