[GNC-dev] Python configs

[Geert Janssens]

Op vrijdag 24 juli 2020 17:45:08 CEST schreef c.holtermann at gmx.de:
> Am 2020-07-23 23:20, schrieb John Ralls:
> > That's just another way of saying you want Python scripting for
> > GnuCash.
> > 
> > I don't remember if a goal beyond showing that it was possible was
> > ever expressed. Certainly no work beyond that was ever done. In
> > addition to the changes I laid out earlier finishing it would require
> > that it gets documented, at least in the wiki but ideally in the Help
> > manual as well. That would still be, along with the rest of the python
> > bindings, essentially a Linux-only feature except for the very few
> > users who can build GnuCash from source on macOS and Windows unless we
> > accept another ~150MB of bloat--about a 30% increase--to include
> > Python in the bundles.
> > 
> > Regards,
> > John Ralls
> 
> Personally I'd like as much python as possible and as you pointed out
> that you main developers want as little as possible I want to figure out
> where to draw the borders.
> 

Again, I have a slightly more nuanced view as John's: we want to support only one scripting 
language. For historical reasons it's guile at the moment, but I'm open to a different one.

That however is just a conceptual idea. In practice migrating to another scripting language is a 
huge undertaking and the most realistic way to achieve that is to reduce the internal 
dependencies on the old scripting language to an absolute minimum. Work on that has been in 
progress for several years - so it's a very slow progress. And our guile's bastion - the report 
system - hasn't ever been considered for conversion yet.

> One example: Personally I would like to draw diagrams in the gnucash gui
> using python. But I understand that that's outside the limits of the
> intended scope of the bindings.

That sounds like you would like to have a report system in python. And that would be required if 
python is to replace guile as gnucash' scripting language.

> The python shell is obviously different from that as it is not external.
> 
> You wrote that the python shell is an unfinished experiment. But when
> the goal was to show that it works then it is a finished experiment
> because it works. At least more or less. Ipython is broken, but that's
> only because it didn't get maintained and that's where I totally
> understand your point that it's important to decide what to implement
> because it needs to be maintained or otherwise will break because the
> rest of the world develops into incompatibility.
> 
> Personally I'd like to keep the python shell for experiments, focussing
> using the python bindings.
> 

That would be fine with me for now. I don't perceive it as a big maintenance burden.

It may be helpful though if we could decide build inclusion of the python module independently 
of the python bindings. Currently both are enabled or disabled together by one cmake switch. 
However only the python module requires linking to a python library if I remember correctly. 
Splitting this configuration could perhaps open the way to python scripting on Windows and/or 
MacOS ? (I have not looked at the code before writing this, so I may be off).

Regards,

Geert