[GNC-dev] Python configs

[John Ralls]

> On Jul 17, 2020, at 12:23 PM, c.holtermann at gmx.de wrote:
> 
> Am 2020-07-17 19:43, schrieb John Ralls:
>>> On Jul 17, 2020, at 2:18 AM, c.holtermann at gmx.de wrote:
>>> 
>>> Hello,
>>> 
>>> I'm thinking about a good place to store python config. That would or
>>> could be:
>>> 
>>> 	* for the python shell
>>> 
>>> 	* if it is activated
>>> 	* I'd like to make a history file and its location configurable
>>> 
>>> 	* for the python example scripts
>>> 
>>> 	* Now or then I have a thought about this or that setting that
>>> doesn't
>>> come to my mind now.
>>> 
>>> Thinking about the activation of the python shell would be enough for
>>> this general question. I don't like to have to change the python shell
>>> source with every new branch or compilation.
>>> 
>>> Could config options use the gnucash config system in which I didn't
>>> really have a look or should it use an own config system with a config
>>> file somewhere where the other gnucash config files reside?
>>> 
>>> I don't know of bindings for the gnucash config system (except for
>>> asking for the --debug and --extra flags as in setup of the python
>>> shell). But I may have missed something.
>> 
>> What exactly are you trying to configure? And what python shell source
>> are you changing for every build?
>> 
>> Bear in mind that we absolutely, positively do NOT want to create a
>> python scripting platform inside of the GnuCash application. Having to
>> deal with Guile is bad enough and adding a second one would square the
>> maintenance effort.
>> 
>> The python bindings are provided for external programs to access
>> GnuCash data. Those programs will have their own configuration needs
>> and where they put their configuration is their developers' problem.
>> 
>> Regards,
>> John Ralls
> 
> Hey John,
> 
> thank you for your reply. I don't want to introduce troublesome things
> that's why I started this general question and thanks to your answer I
> get a better understanding of the core developers position to relate my
> python-positive position to. So I can better see where I may proceed and
> where to stop.
> 
> For the python shell there are two config options:
> 
> a) is the shell activated (
> https://github.com/Gnucash/gnucash/blob/6cb2fa3c3569c5b4597e69c6ca81f866da36a227/gnucash/python/init.py#L110
> )
> b) is it python or ipython ( same file, line 111)
> 
> both are configured in the source code. There is no command-line option
> and no config file to configure this. So every time I fetch a different
> gnucash branch from git I need to reenable it by changing the source.
> This is a bit troublesome and it would be easier to keep a config file
> somewhere with something like
> 
> python-shell-enable = True
> python-shell-type = python
> 
> like log.conf for logging or put the config in any other place in the
> gnucash config realm which I don't yet fully comprehend.
> 
> I don't like to reinvent the wheel and I like to find a good fit to the
> other gnucash infrastructure where possible and suitable.
> 
> I understand your point about scheme and python being a second scripting
> language. It's good to have a common view about the intention and limits
> of the python bindings in the gnucash software and I'm fine with
> agreements and borders.
> 
> I assume I will be asking some more questions about other aspects of
> gnucash and the python-bindings to get a better understanding of the
> intended limits to be better able to 1) help keeping the existing python
> infrastructure stable inside its intented limits 2) define or document
> interfaces to the outside world and 3) develop and keep everything else
> outside gnucash (i.e. in my own repositories).

The underlying problem is that the python console is an unfinished experiment. It needs to either be finished or removed.

The CPython/Iron Python decision is made at build time (libgncmod-python needs to link libpython) so it should be set by Cmake. Startup should be from a menu item somewhere (Tools?), not every time GnuCash starts up based either on a hard-coded constant as it is now nor on a variable read from a config file.

But in light of not wanting to have a Python runtime scripting interface does it really make sense to keep it?

Regards,
John Ralls