Report wrapper to call python scripts?

Thu Dec 25 11:44:22 EST 2014

Hello,

using python and jinjaII templating as I tried for invoices
could be an interesting thing (just for linux).

For reports SciPy would also be tempting.

regards,

Christoph Holtermann

Am 24.12.2014 um 12:49 schrieb Dmitry Pavlov:
> Geert, thank you for a very detailed comments.
>
> I did't know that situation with python bindings is so complicated on
> Windows and OSX, and that can be a real show stopper.
>
> For the details of implementations my idea was slightly different: options
> can be preserved for guile, as options definitions is really the simplest
> part of any current report. The python part was planned to only include
> report generation and guille part should just pass options to that script,
> maybe as command line options or file with that parameters (exact way is
> implemtation details, really).
>
> While I was working on budget report enhancement I've looked at eguile
> reports:
> 1. they are still using scheme to implement report logic, and changes can
> be painfull :)
> 2. template part is full of small scriptlets (scheme code insertions) and
> at least it's worth to make some taglib (sorry for that java world term) so
> that common formatting and type conversion failures can be hidden for
> template authors by simple formatting constructs.
>
> It seems that until python problems can't be solved such report
> implementation can only be a local linux version feature, not included in
> distro. Anyway if some linux user/developer want to participate, I'm ready
> :).
>
> As for more global change, personally me not sure to find enough time and
> scheme knowledge to rewrite many reports at least to eguile, but if I'll
> manage to find time, I'll let you know.
>
> Thank you all for comments!
>
>
> 2014-12-24 14:25 GMT+03:00 Geert Janssens <geert.gnucash at kobaltwit.be>:
>
>>  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
>>
>
>

-- 
--- Nachricht gesendet von C. Holtermann ---
-                                          -
-  Verschlüsselte Nachrichten können über  -
- den öffentlichen Schlüssel auf folgendem -
- Keyserver an mich gesendet werden:       -
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4DD9CF0482B0620B