Am 2020-07-23 23:20, schrieb John Ralls:
On Jul 23, 2020, at 6:57 AM, c.holterm...@gmx.de wrote:
Am 2020-07-17 23:13, schrieb John Ralls:
On Jul 17, 2020, at 12:23 PM, c.holterm...@gmx.de wrote:
Am 2020-07-17 19:43, schrieb John Ralls:
On Jul 17, 2020, at 2:18 AM, c.holterm...@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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
