[GNC-dev] Python configs

[c.holtermann at gmx.de]

Am 2020-07-17 23:13, schrieb 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

I'd be happy if the python console would stay as it allows to work with
the data from the python side while gnucash is running. What were the
goals of the experiment or what do you think would be needed to see it
as finished?

Regards,

Christoph Holtermann