[GNC-dev] Python configs

[c.holtermann at gmx.de]

Am 2020-07-23 23:20, schrieb John Ralls:
>> On Jul 23, 2020, at 6:57 AM, c.holtermann at gmx.de wrote:
>>
>> 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?
>
> 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.

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. I guess I'll draw SciPy diagrams in an
external program. But that has not been an urgent need for me anyway.

You write that you are ok with data access for the python bindings from
external programs.

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.

For the python bindings in respect of data manipulation I see the python
shell (or the underlying interface) as a possibility to work with write
access from the python bindings while gnucash is running. With gnucash
running I can't use the bindings from an external program to manipulate
the same data source - even when using the database interface that would
theoretically be possible - but is not implemented.

Anyway I'd be glad to be in touch about perspectives of the gnucash
python parts. Maybe during gnucash version 4 the fate of the python
shell could be decided. Maybe for the python bindings it could be
possible to come up with something like a plugin system for python
scripts. Basically like the python example scripts. Not maintained by
the core developers. I think the REST-API is a nice example of such a
plugin.

regards,

Christoph Holtermann