[GNC-dev] Python configs

Geert Janssens geert.gnucash at kobaltwit.be
Sat Aug 1 08:32:22 EDT 2020


Op vrijdag 17 juli 2020 23:13:28 CEST schreef 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/6cb2fa3c3569c5b4597e69c6ca81f866da
> > 36a227/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 CPython/Iron Python decision is made at build time (libgncmod-python
> needs to link libpython) so it should be set by Cmake.

I don't think the distinction between python/ipython in init.py refers to the choice of CPython vs 
Iron Python. That indeed is to be decided at build time.

Instead on my Fedora box (which packages CPython) there are two python shells to choose 
from: the python built-in one or an enhanced shell which is named ipython.

> 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.
> 
+1

Make it a menu option that's added via the python module.

That would add the menu item is the python module gets loaded (which in turn would only 
happen if it was effectively built).

The menu could be something like
Tools
-> Python Console
-> -> Default Python
-> -> IPython


More information about the gnucash-devel mailing list