> On Aug 1, 2020, at 5:20 AM, Geert Janssens <geert.gnuc...@kobaltwit.be> wrote:
>
> Op vrijdag 24 juli 2020 17:45:08 CEST schreef c.holterm...@gmx.de:
> > Am 2020-07-23 23:20, schrieb John Ralls:
> > > 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.
> >
>
> Again, I have a slightly more nuanced view as John's: we want to support only
> one scripting language. For historical reasons it's guile at the moment, but
> I'm open to a different one.
>
> That however is just a conceptual idea. In practice migrating to another
> scripting language is a huge undertaking and the most realistic way to
> achieve that is to reduce the internal dependencies on the old scripting
> language to an absolute minimum. Work on that has been in progress for
> several years - so it's a very slow progress. And our guile's bastion - the
> report system - hasn't ever been considered for conversion yet.
>
> > 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.
>
> That sounds like you would like to have a report system in python. And that
> would be required if python is to replace guile as gnucash' scripting
> language.
>
> > 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.
> >
>
> That would be fine with me for now. I don't perceive it as a big maintenance
> burden.
>
> It may be helpful though if we could decide build inclusion of the python
> module independently of the python bindings. Currently both are enabled or
> disabled together by one cmake switch. However only the python module
> requires linking to a python library if I remember correctly. Splitting this
> configuration could perhaps open the way to python scripting on Windows
> and/or MacOS ? (I have not looked at the code before writing this, so I may
> be off).
Nope. Both the bindings and libgncmod-python (for the python console) link
libpython.
The python console isn't really useful without the python bindings, so it could
be made a separate subsidiary enable, but it's pretty light weight so I'm not
sure there'd be much benefit.
Now if we can figure out a way to make libgncmod-python a true plugin that can
be built separately from the rest of GnuCash we could split it out as a
separate project and turn it over to Christoph.
Regards,
John Ralls
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
