Report wrapper to call python scripts?

[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
>



-- 
С уважением,
Дмитрий Павлов