Report wrapper to call python scripts?
Sébastien de Menten
sdementen at gmail.com
Thu Jan 1 17:52:17 EST 2015
I went to explore a bit this path to see its feasibility.
I came with a concrete example of the idea with this single exe (
generated by pyinstaller that takes as argument a python file (and any
extra argument) and run it through python 2.7.
In this example exe, the piecash module is included so that the
piecash_ledger script (
can be run with:
piecash_interpreter.exe piecash_ledger.py mybook.gnucash
Could this be also an option for the official python bindings to ease their
installation on windows (and maybe OS X but I have not OS X machine...) ?
And as possible interface with gnucash and the official python bindings (or
any other bindgins/python executable like piecash ;-) )
On Sun, Dec 28, 2014 at 3:59 PM, John Ralls <jralls at ceridwen.us> wrote:
> > On Dec 27, 2014, at 11:54 PM, Sébastien de Menten <sdementen at gmail.com>
> > Just a thought regarding the need for a python distribution for the
> > binding on Windows/OS X, would it be an option to build a single
> > with the gnucash bindings (see
> > or http://www.decalage.info/en/python/py2exe) ?
> > This would give a complete control on the required python version/package
> > distribution.
> Those solutions are for distributing single applications written in
> Python. They wouldn't do any good for python bindings, where the user
> supplies code. For that we'd have to bundle the entire Python distribution.
> Because of the constraints of linking to a particular libpython on OSX --
> the interpreter and bindings must link to the same libpython, and different
> versions of OSX provide different versions of python, were in the same boat
> there. We'd need to distribute a complete Python installation in the
> GnuCash bundle, and generally users would have to use the python
> interpreter we would ship.
> > And if the user is more knowledgeable re python, it could go with its own
> > distribution (+ other relevant comment in this thread)
> That would require somehow coercing the packages shipped with GnuCash to
> link the library that the interpreter is using. That's not something the
> typical Python programmer thinks much about.
> John Ralls
More information about the gnucash-devel