Sébastien de Menten <sdemen...@gmail.com> writes:
> On Fri, Nov 14, 2014 at 3:33 AM, Derek Atkins <warl...@mit.edu> wrote:
>
> John Ralls <jra...@ceridwen.us> writes:
>
> > What’s your goal here? I don’t think that reimplementing GnuCash in
> > Python with GnuCash’s SQL schema is a particularly good approach: It’s
> > not exactly the most efficient design. Rather, it’s designed to mirror
> > the XML schema. You’ll have a better design if you relegate GnuCash
> > SQL to import/export.
>
> I agree wholeheartedly. Don't do it this way. Use the GnuCash Python
> bindings. If you don't like the current structure of them, then fix
> that. This way your apps will always work because the bindings will
> stay in lockstep with any changes that get made.
>
> Hello Derek,
>
> The GnuCash python bindings are C/SWIG based. This causes some issues on
> windows, and requires deep knowledge of C, SWIG and the GnuCash C api to
> contribute to.
You're right, it causes issues on windows. That's because the bindings
are built against a specific version of Python and windows doesn't have
a canonical version. So we would have to build the wrappers for a
specific version, and possibly even ship it. Not worth it for the very
few people that actually care about Python on Windows.
As for requiring deep knowledge of C and SWIG, that's completely false.
You need a little knowledge about it, sure. But if your goal was to
make the Python bindings more Pythonic, I believe you could do that by
wrapping the existing SWIGified APIs with more Pythonic wrappers. That
would definitely NOT require a "deep knowledge of C" nor "SWIG",
although yes, it would require a deeper knowledge of the GnuCash C API.
> The piecash python bindings are a pure python package ("pip install piecash"
> and you're up and running) and works on the SQL tables through the SQL Alchemy
> library. It is only 500 SLOC today (and may grow in the future but not by an
> order of magnitude). As it is short and in python, it is rather easy to
> contribute/hack/extend.
There's another project, jGnuCashLib, that's a pure Java implementation.
So there is precedent for outside projects to go behind GnuCash's back
to the data file. However, I don't know if jGnuCashLib is read-write or
read-only. However there have been issues in that it only implements
the XML backend, doesn't support compression, and has had issues across
GnuCash releases.
I think most of our beef against your project is that you're making it
read-write. If it was read-only then nobody here would care.
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warl...@mit.edu PGP key available
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
