Python based REST api (was: Gnucash 2.5.0 Release)

Geert Janssens janssens-geert at
Sat Apr 13 08:22:33 EDT 2013

[ Note: I'm redirecting this thread to gnucash-devel as the topic is development related now. Please follow 
up on that list. ]

On Friday 12 April 2013 09:29:20 Tom Lofts wrote:
> Hi Derek,
> On 11/04/13 14:56, Derek Atkins wrote:
> > Would you care to donate this as a contribution to the gnucash release,
> > perhaps under optional/python-bindings/example_scripts ?
> I'd be happy to donate the work I've done so far to the Gnucash project
> - under optional/python-bindings/example_scripts sounds ideal.
That's great! Your contributions are welcome.

> Just a few points on this:
> Will you be integrating this from the github repository, or would you
> like me to send you add this to a copy of the SVN trunk and submit it as
> a diff? If you have an alternative method for submitting patches please
> let me know.

Ideally, you do the integration yourself, and then send in patches we can apply against the master 

One way to do this would be to clone the GnuCash repository on github [1], integrate your work into that 
cloned repository and then use git format-patch to generate a set of patches which you can attach to a bug 
in our bugzilla database [2]. Or if you prefer you can send your patches to the gnucash-devel mailing list 
(which is also the best place to follow up on this, as we are talking about new development). The first 
option is preferred though. Patches on the mailing list are harder to track and sometimes forgotten as a 

> I've made some changes to and also have some changes
> which would be better placed in one of the other python binding files.
> Would you be happy for me to provide updated versions of these files as
> well?
Yes. Given the approach above, this should be part of your patch set already.

> The API so far is work in progress, so has bits of commented out code,
> partially documented functions, bits which don't quite work yet or are
> untested - again I'm quite happy to clean these up before submitting the
> code for release.
That would be very nice. Your code shouldn't be perfect to start, but it helps if it's easy to read for others as 
well and does what it advertises. Further improvements can always be sent in via additional patches later 

> I don't code in python by trade, nor am I familiar with the Gnucash
> internals or accounting practices so I can't promise all the code is
> perfect, but if you're happy to accept it I'd be very happy to help out!
The code doesn't need to be perfect if it does the job. If there are really some conceptual or other 
important flaws in your code, you will likely get feedback that can help you fix those and improve your code. 
That's generally how the GnuCash project works.

> Kind regards,
> Tom

Best regards,


[1] This page shows you how:
[2] Details on our bugzilla database:

More information about the gnucash-devel mailing list