Re: [GNC-dev] [GNC] ofxtools - a Python OFX library
Hello Christopher I am the dev of piecash. Regarding the second resolution of datetime, I think I got it by reverse engineering the SQL database format for gnucash books (you can check by introspecting the DB or the XML). Why do you need this very high resolution? I think most of the datetime elements in gnucash are in fact days represented as datetime with some convention for time (12:00 UTC or more complex logic). On Fri, May 31, 2019, 15:19 Christopher Singley wrote: > Is it a good experience keeping GnuCash books in a SQL backend? There's > much better Python tooling if you can make the interface at SQL. > > Looks like there's piecash, a SQLAlchemy frontend for GnuCash. This > looks promising. It's got good docs, too. > > Is the piecash documentation correct that the GnuCash datetime type is > limited to resolution of seconds rather than microseconds? That would > be unfortunate. > > > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GNUCASH Test Data
Hello Chris, I am definitely interested into such gnucash data set of books/accounts/etc for testing piecash (reports, performance,.. ). With the transition to gnucash 3 coming to maturity, I planned to convert/rework the existing set of sample books ( https://github.com/sdementen/piecash/tree/master/gnucash_books) so if you have something that may be useful in this respect... Did you already share something on GitHub? Sebastien On Sun, Nov 11, 2018, 03:05 David Cousens Chris Millsap, Chris Good > > There is some limited test and example data in the GnuCash sources > .../gnucash-src/doc/examples. Not very extensive. These days a lot of > testing effort is shifted towards unit tests rather than extensive overall > functional tests although they still have a place. I would think there > would > be a serious problem in validation of a data set and then the maintenance > issues you alluded to. Another difficulty would be defining a test data set > which would cover the various feature sets adequately, e.g. business, > trading, multicurrency etc. To define an adequate test data suite would > also > require an extensive knowledge of the code base in any case. > > Possible but is it really worth the effort? In accounting if major features > like compliance with the accounting equation, zero sum for transaction > splits are broken, then it will be generally obvious very quickly and the > unit tests on the engine seem likely pick that up. > > What is it that you would wan't a test data suite to do that is not covered > by the existing unit tests? > > David Cousens > > > > - > David Cousens > -- > Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [PATCH] Switch to python 3
Definitely, I would go for supporting python 3 only. People wanting to use python 2.7 may stay as well with the current 2.6 version or gnucash. On Mar 16, 2018 15:35, "Alen Siljak" <alen.sil...@gmx.com> wrote: > Thanks for the consideration, John. I'm happy to push for adoption of > Python 3 and use that exclusively (as I'm fresh in the Python world). > Sebastien might still be supporting v2 in some projects so let's see what > he has to add. > > > Sent: Friday, March 16, 2018 at 3:26 PM > > From: "John Ralls" <jra...@ceridwen.us> > > To: "Julian Wollrath" <jwollr...@web.de> > > Cc: gnucash-devel@gnucash.org > > Subject: Re: [PATCH] Switch to python 3 > > > > For further discussion here, though, particularly for Sébastien de > Menten and Alen Siljak: Is it OK to convert to Python-3 only or should the > bindings support both Python-2.7 and Python-3 > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: price.date, transaction.post_date and neutral time
r/2012/2018/ (it was a typo) My point is that a price entered via the price editor (manually) is handled differently than a price generated via a transaction and may be (haven't tested) different than a price downloaded via the Finance:Quote module. And indeed, as the time component is meaningless (yet different in function on the price creation method), it shouldn't be stored OR, if for legacy reason it should be kept, it could at least be stored consistently (across price creation method) using for instance the "neutral time" approach used for the post_date. If not, any extract of price data (direct SQL, XML, piecash, ...) is complex to use. On Feb 13, 2018 15:47, "Wm" <wm_o_...@yahoo.co.uk> wrote: > On 13/02/2018 12:47, Sébastien de Menten wrote: > >> On Tue, Feb 13, 2018 at 6:32 AM, Wm via gnucash-devel < >> gnucash-devel@gnucash.org> wrote: >> >> On 12/02/2018 21:00, Sébastien de Menten wrote: >>> >>> When I enter a new price for a given day for a security on the NASDAQ via >>>> the price editor, it is stored in the date column the UTC time for that >>>> day >>>> at 00:00:00 local time (CET=Europe, not EST=New-York). Which is weird >>>> because across timezone, the day of the price will be interpreted >>>> differently. >>>> >>>> >>> Are you entering the prices by hand ? >>> >>> indeed, "via the price editor" (source=user:price-editor in the prices >>> >> table) >> > > OK, I'm not seeing the problem. Isn't gnc behaving as expected ? > > But John R says "that's an absolute time anchored in the market's time >>> >>>> zone, not the user's. " which leaves me puzzled as for the example above >>>> on >>>> the NASDAQ it uses European time (i.e.my local time) not NASDAQ time. >>>> But >>>> maybe when using the Perl finance quote program, there is a more >>>> complete >>>> time information (incl the correct market timezone). >>>> >>>> >>> If you are entering the prices yourself then it seems sensible to me the >>> time is when you made the entry rather than the market's time. >>> >>> yes, indeed. John's comment made me doubt ... >>> >> if I use the price editor for today (source=user:price-editor), I get as >> date 2012/02/12 23:00:00 (because I am in UTC+1) >> if I edit a transaction for today on that commodity >> (source=user:xfer-dialog), then I get as date 2012/02/13 10:59:00 (which >> is >> > > Oh, ffs. Sebastien are you really entering prices from 5 years ago ??? > by hand ??? > and wondering about the fucking time ??? > > I have respect for you. Please have some respect for yourself and how > other people regard you. > > the post_date of the transaction which uses GnuCash "neutral time" concept. >> I haven't tried yet via the Finance:Quote as it doesn't install easily >> under my setup (windows, non admin) but I would be curious to see what >> ends >> up in the date column in this case. >> > > If I look at my raw xml file F::Q gives me > === > > 2018-02-09 12:00:00 + > > === > which is correct, does everyone get something different ? > > I say, if you are entering by hand it *should* be the entry time not the > market time. > > Also, unless you have a special arrangement with a broker, most people >>> don't get a market price, it will be a bit under or over so the market >>> price is just for reference once you include tx costs, etc. >>> >>> Anyway, my question was to understand the reasons of the encoding of a >>> >>>> day/date as an instant/datetime, reasons that are still a bit obscure >>>> (except legacy issue) >>>> >>>> >>> For most purposes it shouldn't matter. The prices db is independent of >>> the actual transactions, it is used for working out the value of stuff >>> and, >>> as I am sure you are aware, the value of commodities changes every minute >>> and second ... gnc is *never* going to keep up with that sort of price >>> change. >>> >>> In retrospect it may be thought that the design mistake was including a >>> time in the price db at all :) >>> >> >> >> That's exaclty my point ;-) >> > > OK, Mr SdM are you saying the point is that there shouldn't be a time at > all ? > > If so I think John said he'll get around to fixing that as and when. I > don't see the point in arguing about an hour or two 5 years ago which seems > to be what you started :( > > -- > Wm > > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: price.date, transaction.post_date and neutral time
On Tue, Feb 13, 2018 at 6:32 AM, Wm via gnucash-devel < gnucash-devel@gnucash.org> wrote: > On 12/02/2018 21:00, Sébastien de Menten wrote: > >> When I enter a new price for a given day for a security on the NASDAQ via >> the price editor, it is stored in the date column the UTC time for that >> day >> at 00:00:00 local time (CET=Europe, not EST=New-York). Which is weird >> because across timezone, the day of the price will be interpreted >> differently. >> > > Are you entering the prices by hand ? > > indeed, "via the price editor" (source=user:price-editor in the prices table) > But John R says "that's an absolute time anchored in the market's time >> zone, not the user's. " which leaves me puzzled as for the example above >> on >> the NASDAQ it uses European time (i.e.my local time) not NASDAQ time. But >> maybe when using the Perl finance quote program, there is a more complete >> time information (incl the correct market timezone). >> > > If you are entering the prices yourself then it seems sensible to me the > time is when you made the entry rather than the market's time. > > yes, indeed. John's comment made me doubt ... if I use the price editor for today (source=user:price-editor), I get as date 2012/02/12 23:00:00 (because I am in UTC+1) if I edit a transaction for today on that commodity (source=user:xfer-dialog), then I get as date 2012/02/13 10:59:00 (which is the post_date of the transaction which uses GnuCash "neutral time" concept. I haven't tried yet via the Finance:Quote as it doesn't install easily under my setup (windows, non admin) but I would be curious to see what ends up in the date column in this case. > Also, unless you have a special arrangement with a broker, most people > don't get a market price, it will be a bit under or over so the market > price is just for reference once you include tx costs, etc. > > Anyway, my question was to understand the reasons of the encoding of a >> day/date as an instant/datetime, reasons that are still a bit obscure >> (except legacy issue) >> > > For most purposes it shouldn't matter. The prices db is independent of > the actual transactions, it is used for working out the value of stuff and, > as I am sure you are aware, the value of commodities changes every minute > and second ... gnc is *never* going to keep up with that sort of price > change. > > In retrospect it may be thought that the design mistake was including a > time in the price db at all :) That's exaclty my point ;-) ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: price.date, transaction.post_date and neutral time
When I enter a new price for a given day for a security on the NASDAQ via the price editor, it is stored in the date column the UTC time for that day at 00:00:00 local time (CET=Europe, not EST=New-York). Which is weird because across timezone, the day of the price will be interpreted differently. But John R says "that's an absolute time anchored in the market's time zone, not the user's. " which leaves me puzzled as for the example above on the NASDAQ it uses European time (i.e.my local time) not NASDAQ time. But maybe when using the Perl finance quote program, there is a more complete time information (incl the correct market timezone). Anyway, my question was to understand the reasons of the encoding of a day/date as an instant/datetime, reasons that are still a bit obscure (except legacy issue) On Feb 12, 2018 15:18, "Wm via gnucash-devel" <gnucash-devel@gnucash.org> wrote: On 11/02/2018 12:33, Sébastien de Menten wrote: > When exporting data from SQL backends, I see some inconsistencies in the > handling of some date & datetime columns. > > In the prices table, when adding price via the price editor, I see in the > date column a datetime with the UTC of the /MM/DD 00:00:00 of my local > timezone (CET). > For instance, for a price on 11/02/2018, I see 2018021023, which is > the UTC value for 11/02/2018 00:00:00+01:00. > What is the reason of having the prices.date as a datetime type (vs a > simple date type) ? > Shouldn't it also be stored as 20180211105900, i.e. in neutral time as the > field transaction.post_date ? > > In the transactions table, the post_date is handled as a date in gnucash > but stored also in a datetime type with the neutral time (10:59:00). > So for a transaction on 11/02/2018, I see 20180211105900. > What is the reason of having the transactions.post_date as a datetime type > (vs a simple date type) ? > > If the reason are mostly legacy, are there some plans to change that in 3.0 > ? > > IIRC the discussion at the time was about whether gnc should or could be used for trading. the result was "no" and it was decided that the price db should only have one entry per day (some people wanted multiple entries per day in an attempt to use gnc for trading, that was never going to work as gnc is a crap model for all the other stuff short term traders need, like quick graphs, moving averages, etc). given that, are you unhappy with the way gnc records date / price combinations ? -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: price.date, transaction.post_date and neutral time
Yes definitely not a top priority if it works and the change is costly and delicate. Regarding prices.date not being handled in neutral time, is there some difference with transactions.post_date regarding it's behavior/type or should it also use neutral time? On Feb 11, 2018 16:53, "John Ralls" <jra...@ceridwen.us> wrote: > > > > On Feb 11, 2018, at 4:33 AM, Sébastien de Menten <sdemen...@gmail.com> > wrote: > > > > When exporting data from SQL backends, I see some inconsistencies in the > > handling of some date & datetime columns. > > > > In the prices table, when adding price via the price editor, I see in the > > date column a datetime with the UTC of the /MM/DD 00:00:00 of my > local > > timezone (CET). > > For instance, for a price on 11/02/2018, I see 2018021023, which is > > the UTC value for 11/02/2018 00:00:00+01:00. > > What is the reason of having the prices.date as a datetime type (vs a > > simple date type) ? > > Shouldn't it also be stored as 20180211105900, i.e. in neutral time as > the > > field transaction.post_date ? > > > > In the transactions table, the post_date is handled as a date in gnucash > > but stored also in a datetime type with the neutral time (10:59:00). > > So for a transaction on 11/02/2018, I see 20180211105900. > > What is the reason of having the transactions.post_date as a datetime > type > > (vs a simple date type) ? > > > > If the reason are mostly legacy, are there some plans to change that in > 3.0 > > ? > > _ > > > The short answer is it’s legacy and while there are plans to perhaps > change it, that didn’t happen in time for GnuCash 3.x and may not for 4.x. > > They’re stored as TIMESTAMP because their internal representation is > effectively time_t, and the internal representation is time_t because when > it was written that’s what was available for time computations... in fact, > until C++17’s std::chrono came along it and its companion struct tm were > still the only standard time representations. > > It’s an incredible amount of work to change the time representation. I > started with 64-bit time and GDateTime in GnuCash 2.6; then we decided to > divorce from GLib and so time that might have gone into reworking > calculations got spent instead on converting to a C++ time implementation, > which at least has the benefit of having an actual date representation > integrated into it (GDate and GDateTime are completely orthogonal). As you > might expect, calculations with post_date are pervasive throughout GnuCash > and changing its representation will be a lot of work. That will happen in > the course of C++ conversion and MVC cleanup, but like so many other things > there’s a lot of preparation first, and frankly there are more important > things to work on. > > Regards, > John Ralls > > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
price.date, transaction.post_date and neutral time
When exporting data from SQL backends, I see some inconsistencies in the handling of some date & datetime columns. In the prices table, when adding price via the price editor, I see in the date column a datetime with the UTC of the /MM/DD 00:00:00 of my local timezone (CET). For instance, for a price on 11/02/2018, I see 2018021023, which is the UTC value for 11/02/2018 00:00:00+01:00. What is the reason of having the prices.date as a datetime type (vs a simple date type) ? Shouldn't it also be stored as 20180211105900, i.e. in neutral time as the field transaction.post_date ? In the transactions table, the post_date is handled as a date in gnucash but stored also in a datetime type with the neutral time (10:59:00). So for a transaction on 11/02/2018, I see 20180211105900. What is the reason of having the transactions.post_date as a datetime type (vs a simple date type) ? If the reason are mostly legacy, are there some plans to change that in 3.0 ? ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: change in date format in 2.7
Thanks for the clarification! On Dec 21, 2017 20:18, "John Ralls" <jra...@ceridwen.us> wrote: That's our general forwards-compatibility guarantee: The last version of 2.6.x is the only version guaranteed to be able to read a 2.8.x database/file. In this case (but not in several others) users will be able to save their databases in another format and read it with earlier versions. I'll have to add a feature flag to prevent earlier 2.6.x versions from opening a file created with >= 2.7.3 (it's obviously too late to add it to 2.7.2). There's an important advantage to using ISO-formatted dates in SQLite3: It allows the same date string can be used to query all three backends. That's not something that we use currently but it will be important as we convert the query system in the next development cycle. Alen has created https://bugzilla.gnome.org/show_bug.cgi?id=791848, let's move the discussion there. Regards, John Ralls > On Dec 21, 2017, at 10:49 AM, Sébastien de Menten <sdemen...@gmail.com> wrote: > > Ok but then it will be semi-backward incompatible as it will be only compatible with 2.6.20 which can make it very tricky for users to test 2.8 and then go back to an old gnucash (if needed) < 2.6.20 the user has using before, no ? > On piecash side, both formats can be supported so it is more for gnucash users than piecash users I am worried. > > On Dec 21, 2017 3:57 PM, "John Ralls" <jra...@ceridwen.us> wrote: > > > > On Dec 21, 2017, at 1:27 AM, Alen Siljak <alen.sil...@gmx.com> wrote: > > > > To get back to Sebastien's question: this does seem like a breaking change at this stage. Going back to 2.6.19 with the database where a few transactions have been entered in 2.7.2 shows the dates as 1970-01-01. > > That’s a significant problem that I’ll have to fix in 2.6.20. Please file a bug report. Thanks. > > Regards, > John Ralls > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
change in date format in 2.7
Hello, In books created in gnucash 2.7, the size of the field for date has been increased from 14 to 19 characters to move from a custom format to an ISO format if I understand properly. This is a backward incompatible change, correct ? ie GC 2.7 will read previous books and "migrate" them to the new format but then the books will not be readable by GC < 2.7. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash 2.7.1: ERROR: Unbound variable: gnc-build-dotgnucash-path
thank you Geert! I've ended up adding (define gnc-build-userdata-path (if (defined? 'gnc-build-userdata-path) gnc-build-userdata-path gnc-build-dotgnucash-path)) in my config.user On Mon, Nov 20, 2017 at 8:03 PM, Geert Janssens <geert.gnuc...@kobaltwit.be> wrote: > Op maandag 20 november 2017 19:48:41 CET schreef Geert Janssens: > > Op maandag 20 november 2017 06:02:20 CET schreef John Ralls: > > > > On Nov 19, 2017, at 8:28 PM, Sébastien de Menten < > sdemen...@gmail.com> > > > > wrote: > > > > > > > > btw, how can I keep backward compatibility in this case so that my > > > > reports > > > > work for both gnucash 2.7/2.8 and gnucash 2.6 ? > > > > > > > > > > > > On Sun, Nov 19, 2017 at 5:51 PM, Sébastien de Menten > > > > <sdemen...@gmail.com > > > > <mailto:sdemen...@gmail.com>> wrote: Ok, thanks for the > clarification. > > > > > > > > On Nov 19, 2017 16:05, "John Ralls" <jra...@ceridwen.us > > > > <mailto:jra...@ceridwen.us>> > > wrote: > > > > > On Nov 19, 2017, at 6:20 AM, Sébastien de Menten < > sdemen...@gmail.com > > > > > <mailto:sdemen...@gmail.com>> wrote: > > > > > > > > > > Not sure if it is a bug with gnucash 2.7.1, but I can't use > > > > > the gnc-build-dotgnucash-path in the config.user as I get an > unbound > > > > > variable. > > > > > any clue? > > > > > is this the right list for questions re gnucash 2.7.1 or should I > use > > > > > the > > > > > gnucash-user ML ? > > > > > > > > It’s renamed to gnc-build-userdata-path. See > > > > libgnucash/core-utils/core-utils.scm. > > > > > > > > Depends on the question. API questions usually belong here. > > > > > > Please remember to copy the list on all replies. > > > > > > The pythonic way would be to catch the unbound variable exception and > try > > > the other one in the handler. > > > > > > Regards, > > > John Ralls > > > > > > ___ > > > gnucash-devel mailing list > > > gnucash-devel@gnucash.org > > > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > > > There was an api change in the way saved reports were stored between 2.4 > and > > 2.6. To make the script work on both 2.4 and 2.6 the following construct > > was used: > > > > (if (defined? 'gnc:restore-report-by-guid-with-custom-template) > > > > > > You can use a similar test for this particular case: > > > > (if (defined? 'gnc-build-userdata-path) > > > > > > Regards, > > > > Geert > > ___ > > gnucash-devel mailing list > > gnucash-devel@gnucash.org > > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > Interestingly half of the example code got stripped somewhere. > > I'll try again, adding some quotation characters: > > > (let ((path (if (defined? 'gnc-build-userdata-path) > > (gnucash-build-userdata-path) > > (gnc-dotgnucash-path)))) > > (do-something-with path)) > > > Geert > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash 2.7.1: ERROR: Unbound variable: gnc-build-dotgnucash-path
yes, the same can be done in scheme but the question is "will scheme reports/scripts need to be rewritten for Gnucash 2.7/2.8?" (i.e. no back compatibility guaranteed) On Mon, Nov 20, 2017 at 5:50 PM, John Ralls <jra...@ceridwen.us> wrote: > > > On Nov 20, 2017, at 1:37 AM, Sébastien de Menten <sdemen...@gmail.com> > wrote: > > Indeed. But in gnucash guile world, how will scm scripts using the old API > still work tomorrow ? Or do they need a migration/versioning per gnucash > version ? > > On Nov 20, 2017 06:04, "John Ralls" <jra...@ceridwen.us> wrote: > >> >> >> On Nov 19, 2017, at 8:28 PM, Sébastien de Menten <sdemen...@gmail.com> >> wrote: >> >> btw, how can I keep backward compatibility in this case so that my >> reports work for both gnucash 2.7/2.8 and gnucash 2.6 ? >> >> >> On Sun, Nov 19, 2017 at 5:51 PM, Sébastien de Menten <sdemen...@gmail.com >> > wrote: >> >>> Ok, thanks for the clarification. >>> >>> On Nov 19, 2017 16:05, "John Ralls" <jra...@ceridwen.us> wrote: >>> >>>> >>>> >>>> > On Nov 19, 2017, at 6:20 AM, Sébastien de Menten <sdemen...@gmail.com> >>>> wrote: >>>> > >>>> > Not sure if it is a bug with gnucash 2.7.1, but I can't use >>>> > the gnc-build-dotgnucash-path in the config.user as I get an unbound >>>> > variable. >>>> > any clue? >>>> > is this the right list for questions re gnucash 2.7.1 or should I use >>>> the >>>> > gnucash-user ML ? >>>> >>>> It’s renamed to gnc-build-userdata-path. See >>>> libgnucash/core-utils/core-utils.scm. >>>> >>>> Depends on the question. API questions usually belong here. >>>> >>> >> Please remember to copy the list on all replies. >> >> The pythonic way would be to catch the unbound variable exception and try >> the other one in the handler. >> > > I’m not much of a schemer so someone more fluent should chime in… but > Scheme also has exceptions so I imagine that the same pattern would work. > > Regards, > John Ralls > > > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash 2.7.1: ERROR: Unbound variable: gnc-build-dotgnucash-path
Indeed. But in gnucash guile world, how will scm scripts using the old API still work tomorrow ? Or do they need a migration/versioning per gnucash version ? On Nov 20, 2017 06:04, "John Ralls" <jra...@ceridwen.us> wrote: > > > On Nov 19, 2017, at 8:28 PM, Sébastien de Menten <sdemen...@gmail.com> > wrote: > > btw, how can I keep backward compatibility in this case so that my reports > work for both gnucash 2.7/2.8 and gnucash 2.6 ? > > > On Sun, Nov 19, 2017 at 5:51 PM, Sébastien de Menten <sdemen...@gmail.com> > wrote: > >> Ok, thanks for the clarification. >> >> On Nov 19, 2017 16:05, "John Ralls" <jra...@ceridwen.us> wrote: >> >>> >>> >>> > On Nov 19, 2017, at 6:20 AM, Sébastien de Menten <sdemen...@gmail.com> >>> wrote: >>> > >>> > Not sure if it is a bug with gnucash 2.7.1, but I can't use >>> > the gnc-build-dotgnucash-path in the config.user as I get an unbound >>> > variable. >>> > any clue? >>> > is this the right list for questions re gnucash 2.7.1 or should I use >>> the >>> > gnucash-user ML ? >>> >>> It’s renamed to gnc-build-userdata-path. See >>> libgnucash/core-utils/core-utils.scm. >>> >>> Depends on the question. API questions usually belong here. >>> >> > Please remember to copy the list on all replies. > > The pythonic way would be to catch the unbound variable exception and try > the other one in the handler. > > Regards, > John Ralls > > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash 2.7.1: ERROR: Unbound variable: gnc-build-dotgnucash-path
Ok, thanks for the clarification. On Nov 19, 2017 16:05, "John Ralls" <jra...@ceridwen.us> wrote: > > > > On Nov 19, 2017, at 6:20 AM, Sébastien de Menten <sdemen...@gmail.com> > wrote: > > > > Not sure if it is a bug with gnucash 2.7.1, but I can't use > > the gnc-build-dotgnucash-path in the config.user as I get an unbound > > variable. > > any clue? > > is this the right list for questions re gnucash 2.7.1 or should I use the > > gnucash-user ML ? > > It’s renamed to gnc-build-userdata-path. See libgnucash/core-utils/core- > utils.scm. > > Depends on the question. API questions usually belong here. > > Regards, > John Ralls > > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
gnucash 2.7.1: ERROR: Unbound variable: gnc-build-dotgnucash-path
Not sure if it is a bug with gnucash 2.7.1, but I can't use the gnc-build-dotgnucash-path in the config.user as I get an unbound variable. any clue? is this the right list for questions re gnucash 2.7.1 or should I use the gnucash-user ML ? ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: update of guile version in windows build
Great! I have installed gnucash 2.7 on windows (downloaded the binaries) but can't make it work. Anyone using the 2.7 binaries for windows successfully? On Nov 14, 2017 11:00 AM, "Geert Janssens" <geert.gnuc...@kobaltwit.be> wrote: Op dinsdag 14 november 2017 09:01:01 CET schreef Sébastien de Menten: > hello, > > What version of guile is packaged with the windows build of gnucash ? > I have the impression it is the 1.8.8 released in 2010 but am not sure... > if so, would it be possible to upgrade it to 2.0 or 2.2 ? > > sebastien Gnucash 2.6 is indeed still shipped with guile 1.8 on Windows. Gnucash 2.7/2.8 will ship guile 2.0 on all platforms. Regards, Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
update of guile version in windows build
hello, What version of guile is packaged with the windows build of gnucash ? I have the impression it is the 1.8.8 released in 2010 but am not sure... if so, would it be possible to upgrade it to 2.0 or 2.2 ? sebastien ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Github projects related to gnucash
Hello, Just to let you know, I have updated the list of github projects with gnucash in their description: http://piecash.readthedocs.io/en/latest/doc/github_links.html Python is the front runner language in terms of # projects followed at some distance by perl and Java. Kind regards, Sébastien ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: display book path in report
I send a pull request for this very small change. btw, when downloading the compressed sources, the swig files are already generated so changing *.i files have no impact which was a bit tricky to understand On Fri, Feb 17, 2017 at 10:36 PM, Derek Atkins <de...@ihtfp.com> wrote: > There is a C API, gnc_get_current_session() defined in gnc-session.h which > you could wrap in engine.i to get gnc-get-current-session, which you could > then use to get call qof-session-get-url. > > It would be a small change to engine.i to wrap the function. Just copy > the existing wrappers for e.g. gnc_get_current_book(). > > -derek > > On Fri, February 17, 2017 4:23 pm, Sébastien de Menten wrote: > > If only I knew how to do this ! I can't find the proper documentation ... > > help much appreciated ! > > > > On Feb 17, 2017 22:14, "Derek Atkins" <de...@ihtfp.com> wrote: > > > >> Actually, qof-session-get-url is already wrapped in the engine module. > >> Also, there is already a (gnc-get-current-book). So all you need to do > >> is > >> find (or add) an API to get the current session from the current book. > >> > >> -derek > >> > >> On Fri, February 17, 2017 4:01 pm, Sébastien de Menten wrote: > >> > I can access a function named qof-session-get-url which expects a > >> session. > >> > However, to get a session, I can only see a qof-session-new that > >> creates > >> a > >> > new session. There is a gnc_get_current_session function but I can't > >> find > >> > how to integrate it in the swig-engine.c file that is generated by > >> swig. > >> > > >> > On Fri, Feb 17, 2017 at 4:56 PM, Derek Atkins <warl...@mit.edu> > wrote: > >> > > >> >> Hard to say. I don't know what other dependencies would need to be > >> >> brought > >> >> in. > >> >> You'd certainly need to rebuild GnuCash! > >> >> > >> >> -derek > >> >> > >> >> Sébastien de Menten <sdemen...@gmail.com> writes: > >> >> > >> >> > Is it complex to add it ? > >> >> > > >> >> > On Feb 16, 2017 16:11, "Derek Atkins" <warl...@mit.edu> wrote: > >> >> > > >> >> > OOPS. You are correct. > >> >> > There is no scheme binding for this API. > >> >> > Sorry. > >> >> > > >> >> > -derek > >> >> > > >> >> > Sébastien de Menten <sdemen...@gmail.com> writes: > >> >> > > >> >> > > I went to look for the file you mentioned and I see it > >> sitting > >> >> in > >> >> the > >> >> > python > >> >> > > bindings folder so I am not sure it is used for scheme. > >> >> > > > >> >> > > On Feb 15, 2017 19:54, "Derek Atkins" <de...@ihtfp.com> > >> wrote: > >> >> > > > >> >> > > Hi, > >> >> > > > >> >> > > I see it included in gnucash_core.i, so I would guess the > >> >> > gnucash-core > >> >> > > module. > >> >> > > > >> >> > > -derek > >> >> > > > >> >> > > On Wed, February 15, 2017 1:40 pm, Sébastien de Menten > >> >> wrote: > >> >> > > > Nice ! > >> >> > > > Do you know in which scheme module are these functions > >> >> located ? > >> >> > What > >> >> > > > extra > >> >> > > > (use-modules xxx) should I add at the beginning of my > >> >> report > >> >> > > > budget-balance-sheet.scm ? > >> >> > > > > >> >> > > > On Feb 15, 2017 16:52, "Derek Atkins" <warl...@mit.edu > > > >> >> wrote: > >> >> > > > > >> >> > > >> Sébastien de Menten <sdemen...@gmail.com> writes: > >> >> > > >> > >> >> > > >> > hello, > >> >
Re: display book path in report
If only I knew how to do this ! I can't find the proper documentation ... help much appreciated ! On Feb 17, 2017 22:14, "Derek Atkins" <de...@ihtfp.com> wrote: > Actually, qof-session-get-url is already wrapped in the engine module. > Also, there is already a (gnc-get-current-book). So all you need to do is > find (or add) an API to get the current session from the current book. > > -derek > > On Fri, February 17, 2017 4:01 pm, Sébastien de Menten wrote: > > I can access a function named qof-session-get-url which expects a > session. > > However, to get a session, I can only see a qof-session-new that creates > a > > new session. There is a gnc_get_current_session function but I can't find > > how to integrate it in the swig-engine.c file that is generated by swig. > > > > On Fri, Feb 17, 2017 at 4:56 PM, Derek Atkins <warl...@mit.edu> wrote: > > > >> Hard to say. I don't know what other dependencies would need to be > >> brought > >> in. > >> You'd certainly need to rebuild GnuCash! > >> > >> -derek > >> > >> Sébastien de Menten <sdemen...@gmail.com> writes: > >> > >> > Is it complex to add it ? > >> > > >> > On Feb 16, 2017 16:11, "Derek Atkins" <warl...@mit.edu> wrote: > >> > > >> > OOPS. You are correct. > >> > There is no scheme binding for this API. > >> > Sorry. > >> > > >> > -derek > >> > > >> > Sébastien de Menten <sdemen...@gmail.com> writes: > >> > > >> > > I went to look for the file you mentioned and I see it sitting > >> in > >> the > >> > python > >> > > bindings folder so I am not sure it is used for scheme. > >> > > > >> > > On Feb 15, 2017 19:54, "Derek Atkins" <de...@ihtfp.com> wrote: > >> > > > >> > > Hi, > >> > > > >> > > I see it included in gnucash_core.i, so I would guess the > >> > gnucash-core > >> > > module. > >> > > > >> > > -derek > >> > > > >> > > On Wed, February 15, 2017 1:40 pm, Sébastien de Menten > >> wrote: > >> > > > Nice ! > >> > > > Do you know in which scheme module are these functions > >> located ? > >> > What > >> > > > extra > >> > > > (use-modules xxx) should I add at the beginning of my > >> report > >> > > > budget-balance-sheet.scm ? > >> > > > > >> > > > On Feb 15, 2017 16:52, "Derek Atkins" <warl...@mit.edu> > >> wrote: > >> > > > > >> > > >> Sébastien de Menten <sdemen...@gmail.com> writes: > >> > > >> > >> > > >> > hello, > >> > > >> > > >> > > >> > Is it possible to have the path of the gnucash book > >> > > >> (c:\...\mybook.gnucash) > >> > > >> > displayed in the reports so that I can easily identify > >> to > >> which > >> > book > >> > > a > >> > > >> > report relates (e.g. once printed) ? > >> > > >> > >> > > >> You could use qof_session_get_file_path() and/or > >> > qof_session_get_url() > >> > > >> to obtain that information from the current session. > >> C.f. > >> > > >> http://code.gnucash.org/docs/MAINT/group__Backend.html# > >> > > >> gaef36a80fef74a21750fe98ba24a2e19c > >> > > >> > >> > > >> > sebastien > >> > > >> > >> > > >> > Please remember to CC this list on all your replies. > >> > > >> > You can do this by using Reply-To-List or Reply-All. > >> > > >> > >> > > >> -derek > >> > > >> > >> > > >> -- > >> > > >>Derek Atkins, SB '93 MIT EE, SM '95 MIT Media > >> Laboratory > >> >
Re: display book path in report
I can access a function named qof-session-get-url which expects a session. However, to get a session, I can only see a qof-session-new that creates a new session. There is a gnc_get_current_session function but I can't find how to integrate it in the swig-engine.c file that is generated by swig. On Fri, Feb 17, 2017 at 4:56 PM, Derek Atkins <warl...@mit.edu> wrote: > Hard to say. I don't know what other dependencies would need to be brought > in. > You'd certainly need to rebuild GnuCash! > > -derek > > Sébastien de Menten <sdemen...@gmail.com> writes: > > > Is it complex to add it ? > > > > On Feb 16, 2017 16:11, "Derek Atkins" <warl...@mit.edu> wrote: > > > > OOPS. You are correct. > > There is no scheme binding for this API. > > Sorry. > > > > -derek > > > > Sébastien de Menten <sdemen...@gmail.com> writes: > > > > > I went to look for the file you mentioned and I see it sitting in > the > > python > > > bindings folder so I am not sure it is used for scheme. > > > > > > On Feb 15, 2017 19:54, "Derek Atkins" <de...@ihtfp.com> wrote: > > > > > > Hi, > > > > > > I see it included in gnucash_core.i, so I would guess the > > gnucash-core > > > module. > > > > > > -derek > > > > > > On Wed, February 15, 2017 1:40 pm, Sébastien de Menten wrote: > > > > Nice ! > > > > Do you know in which scheme module are these functions > located ? > > What > > > > extra > > > > (use-modules xxx) should I add at the beginning of my report > > > > budget-balance-sheet.scm ? > > > > > > > > On Feb 15, 2017 16:52, "Derek Atkins" <warl...@mit.edu> > wrote: > > > > > > > >> Sébastien de Menten <sdemen...@gmail.com> writes: > > > >> > > > >> > hello, > > > >> > > > > >> > Is it possible to have the path of the gnucash book > > > >> (c:\...\mybook.gnucash) > > > >> > displayed in the reports so that I can easily identify to > which > > book > > > a > > > >> > report relates (e.g. once printed) ? > > > >> > > > >> You could use qof_session_get_file_path() and/or > > qof_session_get_url() > > > >> to obtain that information from the current session. C.f. > > > >> http://code.gnucash.org/docs/MAINT/group__Backend.html# > > > >> gaef36a80fef74a21750fe98ba24a2e19c > > > >> > > > >> > sebastien > > > >> > > > >> > Please remember to CC this list on all your replies. > > > >> > You can do this by using Reply-To-List or Reply-All. > > > >> > > > >> -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.eduPGP key > available > > > >> > > > > > > > > > > -- > > >Derek Atkins 617-623-3745 > > >de...@ihtfp.com www.ihtfp.com > > >Computer and Internet Security Consultant > > > > > > > -- > >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.eduPGP key available > > > > -- >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.eduPGP key available > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: display book path in report
Is it complex to add it ? On Feb 16, 2017 16:11, "Derek Atkins" <warl...@mit.edu> wrote: > OOPS. You are correct. > There is no scheme binding for this API. > Sorry. > > -derek > > Sébastien de Menten <sdemen...@gmail.com> writes: > > > I went to look for the file you mentioned and I see it sitting in the > python > > bindings folder so I am not sure it is used for scheme. > > > > On Feb 15, 2017 19:54, "Derek Atkins" <de...@ihtfp.com> wrote: > > > > Hi, > > > > I see it included in gnucash_core.i, so I would guess the > gnucash-core > > module. > > > > -derek > > > > On Wed, February 15, 2017 1:40 pm, Sébastien de Menten wrote: > > > Nice ! > > > Do you know in which scheme module are these functions located ? > What > > > extra > > > (use-modules xxx) should I add at the beginning of my report > > > budget-balance-sheet.scm ? > > > > > > On Feb 15, 2017 16:52, "Derek Atkins" <warl...@mit.edu> wrote: > > > > > >> Sébastien de Menten <sdemen...@gmail.com> writes: > > >> > > >> > hello, > > >> > > > >> > Is it possible to have the path of the gnucash book > > >> (c:\...\mybook.gnucash) > > >> > displayed in the reports so that I can easily identify to which > book > > a > > >> > report relates (e.g. once printed) ? > > >> > > >> You could use qof_session_get_file_path() and/or > qof_session_get_url() > > >> to obtain that information from the current session. C.f. > > >> http://code.gnucash.org/docs/MAINT/group__Backend.html# > > >> gaef36a80fef74a21750fe98ba24a2e19c > > >> > > >> > sebastien > > >> > > >> > Please remember to CC this list on all your replies. > > >> > You can do this by using Reply-To-List or Reply-All. > > >> > > >> -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.eduPGP key available > > >> > > > > > > > -- > >Derek Atkins 617-623-3745 > >de...@ihtfp.com www.ihtfp.com > >Computer and Internet Security Consultant > > > > -- >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.eduPGP key available > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: report in python, a first version
On Nov 16, 2016 12:30 AM, "John Ralls" <jra...@ceridwen.us> wrote: > > > > On Nov 15, 2016, at 12:58 PM, Sébastien de Menten <sdemen...@gmail.com> wrote: > > > > > > On Tue, Nov 15, 2016 at 6:41 PM, John Ralls <jra...@ceridwen.us> wrote: > > > > > On Nov 15, 2016, at 9:24 AM, Sébastien de Menten <sdemen...@gmail.com> wrote: > > > > > > On Tue, Nov 15, 2016 at 4:17 PM, John Ralls <jra...@ceridwen.us> wrote: > > > > > > Sébastien, > > > > > > That's a bit more "external" than I had in mind. The plug/connect any process part is a serious security issue. > > > > > > I don't understand the point of the json file. Users will want the report to display and then to be able to open the report options dialog to make changes like selecting a date range or modifying the accounts reported on, and expect the report to regenerate when they click "Apply". ISTM to accomplish that the report module needs to be in control and to pass to the Python report-builder the options parameters. The second thing that won't work is using PyCash: The user wants a report on what her book looks like in memory, not what it looked like the last time she saved, so the report will need to use the python bindings and connect to the current session. > > > > > > It looks to me from the Makefile.am that building guile-json requires Guile-2.0, which you won't have if you're using the Guile in the GnuCash Windows installation. You could try to simply copy the four .scm files into share/guile/1.8/ and see if it works. It will only if the author didn't use any Guile-2-only features. > > > > > > Regards, > > > John Ralls > > > > > > > > > On the security risk, it is no different than running the same process outside GnuCash (in a terminal for instance), or is it ? > > > The json file is there to be able to specify the options for a report in a better way than writing Scheme in an scm file. Currently, for a given python report (report_test.py), I generate the Scheme code wrapping this python report (report_test.scm) with: > > > - the proper Scheme code for the options defined in report_test.py > > > - the proper Scheme code to call the python process (ie "python report_test.py") > > > Instead of having to generate scheme code, it would be better to have a json file per report (report_test.json) that could be used to instantiate the report in GnuCash. > > > > > > For piecash, there is no specific issue as the change in the book are immediately serialised to the SQL backend. However, for the xml backend (that piecash does not support anyway), the GnuCash file should be saved before. But nothing forbids someone to use the official python bindings to connect to the current session and do as you describe. However, how the python bindings know to which session to connect if there are multiple files opened at the same time ? and can they open a session in a separate process while GnuCash has a lock on the file ? > > > > > > > Sébastien, > > > > A process running outside GnuCash isn't pushing data into a running instance of GnuCash, so yes, it's significantly different. The ancient libwebkit we use has tons of known vulnerabilities that could be exploited by injecting malicious HTML or JavaScript. > > > > > > Any report written in guile can be malicious as it has (i guess) full access to the OS (syscall, file manipulation, etc) and to the gnucash engine (I guess the report could modify the book ... but I may be wrong). Any outside process can tinker with the gnucash books to corrupt them. So I do not see exactly what specific security threat would be avoided by blocking the specific case of a process running outside Gnucash pushing a string of HTML. > > > > > > Maybe I misunderstand how the json file would work. Would it just initialize the options which can then be edited in the report's options dialog, or are the options in the json file the ones that the report gets and the user must edit the json file in order to change them? > > > > Indeed, the json is just there to 1) initalise the 'options-generator' object (with the options information), 2) specify the process to call (via dynamic-wind) and 3) define the report (argument for 'gnc:define-report). It is just way more readable/editable than tinkering with scm code. But we could choose yaml (even more readable but must find a yaml parser for guile) or xml (less readable but xml reader available in standard guile library?). > > > > Does PyCash ignore the lock table in the database, then? > > > > > > piecash is well aware of the lock table in the database but you can tell him to igno
Re: report in python, a first version
On Tue, Nov 15, 2016 at 6:41 PM, John Ralls <jra...@ceridwen.us> wrote: > > > On Nov 15, 2016, at 9:24 AM, Sébastien de Menten <sdemen...@gmail.com> > wrote: > > > > On Tue, Nov 15, 2016 at 4:17 PM, John Ralls <jra...@ceridwen.us> wrote: > > > > Sébastien, > > > > That's a bit more "external" than I had in mind. The plug/connect any > process part is a serious security issue. > > > > I don't understand the point of the json file. Users will want the > report to display and then to be able to open the report options dialog to > make changes like selecting a date range or modifying the accounts reported > on, and expect the report to regenerate when they click "Apply". ISTM to > accomplish that the report module needs to be in control and to pass to the > Python report-builder the options parameters. The second thing that won't > work is using PyCash: The user wants a report on what her book looks like > in memory, not what it looked like the last time she saved, so the report > will need to use the python bindings and connect to the current session. > > > > It looks to me from the Makefile.am that building guile-json requires > Guile-2.0, which you won't have if you're using the Guile in the GnuCash > Windows installation. You could try to simply copy the four .scm files into > share/guile/1.8/ and see if it works. It will only if the author didn't use > any Guile-2-only features. > > > > Regards, > > John Ralls > > > > > > On the security risk, it is no different than running the same process > outside GnuCash (in a terminal for instance), or is it ? > > The json file is there to be able to specify the options for a report in > a better way than writing Scheme in an scm file. Currently, for a given > python report (report_test.py), I generate the Scheme code wrapping this > python report (report_test.scm) with: > > - the proper Scheme code for the options defined in report_test.py > > - the proper Scheme code to call the python process (ie "python > report_test.py") > > Instead of having to generate scheme code, it would be better to have a > json file per report (report_test.json) that could be used to instantiate > the report in GnuCash. > > > > For piecash, there is no specific issue as the change in the book are > immediately serialised to the SQL backend. However, for the xml backend > (that piecash does not support anyway), the GnuCash file should be saved > before. But nothing forbids someone to use the official python bindings to > connect to the current session and do as you describe. However, how the > python bindings know to which session to connect if there are multiple > files opened at the same time ? and can they open a session in a separate > process while GnuCash has a lock on the file ? > > > > Sébastien, > > A process running outside GnuCash isn't pushing data into a running > instance of GnuCash, so yes, it's significantly different. The ancient > libwebkit we use has tons of known vulnerabilities that could be exploited > by injecting malicious HTML or JavaScript. > > Any report written in guile can be malicious as it has (i guess) full access to the OS (syscall, file manipulation, etc) and to the gnucash engine (I guess the report could modify the book ... but I may be wrong). Any outside process can tinker with the gnucash books to corrupt them. So I do not see exactly what specific security threat would be avoided by blocking the specific case of a process running outside Gnucash pushing a string of HTML. > Maybe I misunderstand how the json file would work. Would it just > initialize the options which can then be edited in the report's options > dialog, or are the options in the json file the ones that the report gets > and the user must edit the json file in order to change them? > > Indeed, the json is just there to 1) initalise the 'options-generator' object (with the options information), 2) specify the process to call (via dynamic-wind) and 3) define the report (argument for 'gnc:define-report). It is just way more readable/editable than tinkering with scm code. But we could choose yaml (even more readable but must find a yaml parser for guile) or xml (less readable but xml reader available in standard guile library?). > Does PyCash ignore the lock table in the database, then? > > piecash is well aware of the lock table in the database but you can tell him to ignore it if you open the book in read only mode via book = piecash.open_book(book_url, readonly=True, open_if_lock=True) > To connect to the current session I think one would need to use the Python > connection in src/python or the Scheme interpreter. No external process is
Re: report in python, a first version
On Tue, Nov 15, 2016 at 4:17 PM, John Ralls <jra...@ceridwen.us> wrote:
>
> On Nov 14, 2016, at 10:43 PM, Sébastien de Menten <sdemen...@gmail.com>
> wrote:
>
>
> On Tue, Nov 15, 2016 at 5:37 AM, John Ralls <jra...@ceridwen.us> wrote:
>
>>
>> On Nov 14, 2016, at 7:05 PM, Sébastien de Menten <sdemen...@gmail.com>
>> wrote:
>>
>> On Nov 15, 2016 1:27 AM, "John Ralls" <jra...@ceridwen.us> wrote:
>> >
>> >
>> > > On Nov 14, 2016, at 1:31 PM, Sébastien de Menten <sdemen...@gmail.com>
>> wrote:
>> > >
>> > > Hello,
>> > >
>> > > I have finished a first version of a mechanism to use python for
>> reporting
>> > > in gnucash.
>> > > It uses a scheme script to start a python process that does the heavy
>> > > lifthing.
>> > >
>> > > Should you be interested, you can find documentation/instructions
>> here:
>> > > http://gnucash-utilities.readthedocs.io/en/master/doc/doc.
>> html#report-creation-linux-and-windows-python-3-5
>> > > as well as an example of the simplest report possible
>> > > http://gnucash-utilities.readthedocs.io/en/master/doc/doc.
>> html#a-simple-report
>> > >
>> > > Any feedback appreciated.
>> >
>> > Sébastien,
>> >
>> > Did you decide to not use the facility in src/optional/python to start
>> a Python interpreter inside of GnuCash because you didn't know about it,
>> because it was easier to do something in Scheme, or because that
>> interpreter can't interact with the existing (Scheme) report facilities?
>> >
>> > Regards,
>> > John Ralls
>> >
>>
>> I didn't (and still don't) know a lot about this embedded python
>> interpreter. Any link pointing to doc by any chance ?
>> I wanted something that could leverage the "report options" framework
>> (this is purely in scheme, correct ?), could be hot plugable on gnucash (no
>> recompilation) and rather generic (the subprocess can be any specific
>> python intepreter, usually one in a virtualenv, but this could be adapted
>> to launch any subprocess ... perl ? node.js ?).
>> I therefore hacked a way via scheme reusing logic found in the quote
>> updater to spawn external processes.
>> If anything can be simplified/better designed, I am in.
>>
>>
>> Sébastien,
>>
>> Sorry, wrong directory. The regular python bindings are in
>> src/optional/python; the embedded interpreter is in src/python.
>> I don't think there's any docs beyond whatever comments are in the
>> module. History says it was a drive-by contribution 5+ years ago that
>> Christian polished up a bit and committed.
>>
>> Options, including report options but not preferences, are a horror-show
>> that bounces back and forth between C and Scheme. The C bits are obviously
>> swigged so that Scheme can see them. IIRC (I haven't looked at it in a bit
>> over a year) Scheme passes callbacks to C rather than there being anything
>> directly callable from C, so any Python code that wanted to get at it would
>> have to duplicate the Scheme part of the functionality. There might be a
>> way to get at the Scheme functions via Guile (whose internals are exposed
>> both as C and Scheme), but it wouldn't be a trivial undertaking.
>>
>> Regards,
>> John Ralls
>>
>>
> That's what I "feared" (to dig up all the dirt) and that led me to the
> decision to keep Scheme as an "entry point".
> A path to improve (and generalise) the current solution I built could be :
> - have in config.user the ability to load a report by reading a json file
>
> (load-report-from-json (gnc-build-dotgnucash-path "my_report.json"))
>
> with my_report.json being something like
>
> {
> "_type": "report",
> "title": "My simplest report",
> "name": "piecash-simple-report",
> "menu_tip": "This simple report ever",
> "options_default_section": "general",
> "options": [
> {
> "_type": "option-range",
> "name": "my_number", "section": "main",
> "sort_tag": "a",
> "documentation_string": "This is a number",
> "default_value": 3
> },
> {
> "_type": "option-date", "name": "my_date",
> &quo
Re: report in python, a first version
On Tue, Nov 15, 2016 at 5:37 AM, John Ralls <jra...@ceridwen.us> wrote:
>
> On Nov 14, 2016, at 7:05 PM, Sébastien de Menten <sdemen...@gmail.com>
> wrote:
>
> On Nov 15, 2016 1:27 AM, "John Ralls" <jra...@ceridwen.us> wrote:
> >
> >
> > > On Nov 14, 2016, at 1:31 PM, Sébastien de Menten <sdemen...@gmail.com>
> wrote:
> > >
> > > Hello,
> > >
> > > I have finished a first version of a mechanism to use python for
> reporting
> > > in gnucash.
> > > It uses a scheme script to start a python process that does the heavy
> > > lifthing.
> > >
> > > Should you be interested, you can find documentation/instructions here:
> > > http://gnucash-utilities.readthedocs.io/en/master/doc/
> doc.html#report-creation-linux-and-windows-python-3-5
> > > as well as an example of the simplest report possible
> > > http://gnucash-utilities.readthedocs.io/en/master/doc/
> doc.html#a-simple-report
> > >
> > > Any feedback appreciated.
> >
> > Sébastien,
> >
> > Did you decide to not use the facility in src/optional/python to start a
> Python interpreter inside of GnuCash because you didn't know about it,
> because it was easier to do something in Scheme, or because that
> interpreter can't interact with the existing (Scheme) report facilities?
> >
> > Regards,
> > John Ralls
> >
>
> I didn't (and still don't) know a lot about this embedded python
> interpreter. Any link pointing to doc by any chance ?
> I wanted something that could leverage the "report options" framework
> (this is purely in scheme, correct ?), could be hot plugable on gnucash (no
> recompilation) and rather generic (the subprocess can be any specific
> python intepreter, usually one in a virtualenv, but this could be adapted
> to launch any subprocess ... perl ? node.js ?).
> I therefore hacked a way via scheme reusing logic found in the quote
> updater to spawn external processes.
> If anything can be simplified/better designed, I am in.
>
>
> Sébastien,
>
> Sorry, wrong directory. The regular python bindings are in
> src/optional/python; the embedded interpreter is in src/python.
> I don't think there's any docs beyond whatever comments are in the module.
> History says it was a drive-by contribution 5+ years ago that Christian
> polished up a bit and committed.
>
> Options, including report options but not preferences, are a horror-show
> that bounces back and forth between C and Scheme. The C bits are obviously
> swigged so that Scheme can see them. IIRC (I haven't looked at it in a bit
> over a year) Scheme passes callbacks to C rather than there being anything
> directly callable from C, so any Python code that wanted to get at it would
> have to duplicate the Scheme part of the functionality. There might be a
> way to get at the Scheme functions via Guile (whose internals are exposed
> both as C and Scheme), but it wouldn't be a trivial undertaking.
>
> Regards,
> John Ralls
>
>
That's what I "feared" (to dig up all the dirt) and that led me to the
decision to keep Scheme as an "entry point".
A path to improve (and generalise) the current solution I built could be :
- have in config.user the ability to load a report by reading a json file
(load-report-from-json (gnc-build-dotgnucash-path "my_report.json"))
with my_report.json being something like
{
"_type": "report",
"title": "My simplest report",
"name": "piecash-simple-report",
"menu_tip": "This simple report ever",
"options_default_section": "general",
"options": [
{
"_type": "option-range",
"name": "my_number", "section": "main",
"sort_tag": "a",
"documentation_string": "This is a number",
"default_value": 3
},
{
"_type": "option-date", "name": "my_date",
"section": "main",
"sort_tag": "b",
"documentation_string": "This is a date",
"default_value": "today"
}
],
"process_win" : "c:\path\to\chosen\python\interpreter\pythonw.exe",
"process_OSX" : "/path/to/chosen/python/interpreter/python",
"process_linux" : "/path/to/chosen/python/interpreter/python",
"process_arguments": []
}
The Scheme function would then load (dynamically if possible or at start
time if not possible) this file an
Re: report in python, a first version
On Nov 15, 2016 1:27 AM, "John Ralls" <jra...@ceridwen.us> wrote: > > > > On Nov 14, 2016, at 1:31 PM, Sébastien de Menten <sdemen...@gmail.com> wrote: > > > > Hello, > > > > I have finished a first version of a mechanism to use python for reporting > > in gnucash. > > It uses a scheme script to start a python process that does the heavy > > lifthing. > > > > Should you be interested, you can find documentation/instructions here: > > http://gnucash-utilities.readthedocs.io/en/master/doc/doc.html#report-creation-linux-and-windows-python-3-5 > > as well as an example of the simplest report possible > > http://gnucash-utilities.readthedocs.io/en/master/doc/doc.html#a-simple-report > > > > Any feedback appreciated. > > Sébastien, > > Did you decide to not use the facility in src/optional/python to start a Python interpreter inside of GnuCash because you didn't know about it, because it was easier to do something in Scheme, or because that interpreter can't interact with the existing (Scheme) report facilities? > > Regards, > John Ralls > I didn't (and still don't) know a lot about this embedded python interpreter. Any link pointing to doc by any chance ? I wanted something that could leverage the "report options" framework (this is purely in scheme, correct ?), could be hot plugable on gnucash (no recompilation) and rather generic (the subprocess can be any specific python intepreter, usually one in a virtualenv, but this could be adapted to launch any subprocess ... perl ? node.js ?). I therefore hacked a way via scheme reusing logic found in the quote updater to spawn external processes. If anything can be simplified/better designed, I am in. Sebastien ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
report in python, a first version
Hello, I have finished a first version of a mechanism to use python for reporting in gnucash. It uses a scheme script to start a python process that does the heavy lifthing. Should you be interested, you can find documentation/instructions here: http://gnucash-utilities.readthedocs.io/en/master/doc/doc.html#report-creation-linux-and-windows-python-3-5 as well as an example of the simplest report possible http://gnucash-utilities.readthedocs.io/en/master/doc/doc.html#a-simple-report Any feedback appreciated. Sebastien ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Fwd: Guile gnucash modules documentation
Cross posting to gnucash-devel as probably more a dev question. Essentially: is there any way to get some documentation (even just the list of modules with symbols exported) on the guile gnucash bindings ? Sébastien -- Forwarded message -- From: "Sébastien de Menten" <sdemen...@gmail.com> Date: Nov 2, 2016 02:00 Subject: Guile gnucash modules documentation To: <gnucash-u...@gnucash.org> Cc: Is there a place where we can find documentation on the functions available > from guile to write report ? > Diving back in scheme bring good memories but these are not sufficient to > understand how to use guile with gnucash. > For instance, how can I get back just the current session ? > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
two children account may have the same name
There is no constraint in gnucash to avoid creating two top-level accounts with the same name while there is such a constraint for two sub-accounts. Should the first be allowed ? Is there some reason to allow this ? regards sebastien ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
announcement beta release of piecash, an alternative python interface to GnuCash
Seen the recent emails on the gnucash mailing lists about several topics for which the project I am working on could be deemed interesting, I announce you that version 0.62 of piecash, an alternative python interface to GnuCash, is released. I made two simple screencasts to show its use (to be watched in 720p HD) https://www.youtube.com/watch?v=VbyqRu1KZMo https://www.youtube.com/watch?v=-Q5zgJxWgd0 (as they show the ability to create and modify GnuCash file, their target audience can be considered as advanced user with python knowledge or whoever wanting to go this way). Besides what is shown in the screencasts, piecash has also a basic QIF and Ledger exporter. Writing custom QIF or CSV importers is definitely something that can be done. This was my primary need for piecash. I used successfully piecash to import different information (accounts trees, transactions, ...) from custom text files into GnuCash. Regarding SQL reports, piecash is built on top of sqlalchemy. It is therefore possible to use it to write queries in a backend agnostic way, queries that sqlalchemy will properly translate to the proper dialect. piecash has been essentially tested with sqlite and also, but moderately, with PostgreSQL. For document generation (reports, invoices, ...), piecash can be used with a templating language (e.g. jinja2) to customise latex templates. It can also be used in conjunction with other python packages to create PDFs. Finally, piecash is simple to install (on windows and on linux) as it is a pure python package. It is not tied to a GnuCash binaries/libraries (in fact, it can run without GnuCash being installed at all) and so do not need to be updated at each release of GnuCash. As piecash is not part of the GnuCash project, discussing piecash related email in the GnuCash mailing list is not appropriate (this email being an exception ;-) ). If you have piecash specific questions or want to discuss on the project, I would kindly suggest you to use the google group/forum I set up at https://groups.google.com/forum/#!forum/piecash kr Sebastien ps: as with any other software that uses your data files, please always backup your files before using piecash ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
FOSDEM
Anyone attending FOSDEM next weekend ? ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
CRIT log when reading file with new name for the first time
I noticed in the log /tmp/gnucash.trace that whenever I rename a gnucash sqlite file and I open it in gnucash, Gnucash leaves a CRITical warning in it: * 21:02:56 CRIT GLib g_key_file_free: assertion 'key_file != NULL' failed * 21:02:56 INFO gnc.app-utils [gnc_state_get_current] No pre-existing state found, creating new one Reading the line just after (that is only there when the CRIT message is there), I guess it is because gnucash does not find the file in its ~/.gnucash/books folder. Could someone confirm it is not that a CRITical warning ? ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
understanding scheduled transactions sql table
For each scheduled transaction, I can see that a BANK account is created as a child of the root_template, with as name the guid of the scheduled transaction. This account does not have a lot of valuable information (field or slots) at first sight. What would be the role of this account ? kr sebastien ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Report wrapper to call python scripts?
Hello John, 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 ( https://github.com/sdementen/piecash/blob/master/piecash_interpreter/piecash_interpreter.exe?raw=true) 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 ( https://github.com/sdementen/piecash/blob/master/piecash_interpreter/piecash_interpreter.exe?raw=true) 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 ;-) ) sebastien On Sun, Dec 28, 2014 at 3:59 PM, John Ralls jra...@ceridwen.us wrote: On Dec 27, 2014, at 11:54 PM, Sébastien de Menten sdemen...@gmail.com wrote: Just a thought regarding the need for a python distribution for the python binding on Windows/OS X, would it be an option to build a single executable with the gnucash bindings (see http://www.orbitals.com/programs/pyexe.html 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. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
some questions on accounts/commodities
hello, I have some questions on gnucash behavior regarding some limit changes: - a placeholder account: an account can be converted to a placeholder account even if there are splits related to it. Is it expected behavior ? or should the placeholder flag be selectable only if there are no split in the account. - once an account has splits, it is still possible to change the commodity of the account (ie we can move from EUR to YHOO stock without any warning). Is it expected behavior ? - once an account has splits, it is still possible to change the commodity_scu (smallest fraction) of the account (ie we can move from 1/100 to 1/10). The existing splits are not adjusted to the new commodity_scu. Is it expected behavior ? - similarly the fraction traded in a commodity (non currency) can be changed even though accounts related to it have already splits that may use higher precision that the new fraction traded. Is it expected behavior ? - in the security editor, are symbol/abbreviation and display symbol the same field ? I was wondering if there was not a set of characteristics of the accounts/commodity that are write once (ie, they are defined at the creation of the account/commodity but they can't be modified once they have other objects, like splits, relating to them). Is it more or less correct ? kr sebastien ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: some questions on accounts/commodities
On Mon, Dec 29, 2014 at 6:36 PM, John Ralls jra...@ceridwen.us wrote: On Dec 29, 2014, at 7:17 AM, Sébastien de Menten sdemen...@gmail.com wrote: hello, I have some questions on gnucash behavior regarding some limit changes: - a placeholder account: an account can be converted to a placeholder account even if there are splits related to it. Is it expected behavior ? or should the placeholder flag be selectable only if there are no split in the account. Expected, because one use of placeholder is to freeze an account, perhaps because it's been closed. Indeed, it makes sense. On 2.6.4, if an account is opened (ie I see the ledger) and I change the placeholder flag of the account to True, I still can add new transactions/splits. If I close the account and reopen it, then it is indeed impossible to add new ones. It could be worth to clarify a little bit the documentation with A *Placeholder* means this account is not used for *new *transaction data. *New* transactions may not be posted to this account, only to sub-accounts of this account not marked themselves as *Placeholder*. - once an account has splits, it is still possible to change the commodity of the account (ie we can move from EUR to YHOO stock without any warning). Is it expected behavior ? Expected behavior. Countries change currency (adoption of the Euro being the most common case, but others include Zimbabwe's adoption of the USD after the collapse of their own currency). There's code in the engine to recalculate all of the existing splits in the new commodity. When I change the account commodity in GnuCash, I do not see any code running to propose some currency conversion for the current splits (with or without trading accounts). Is it normal ? How can I trigger the recalculation of the existing splits ? In case of change of currency in a country, shouldn't the old transactions/splits be kept in the old currency, the new in the new and the balance, at a given time, changed from the old to the new currency ? (I'm just thinking out loud...). Otherwise, how (which FX rate) are converted the old splits in the new currency ? - once an account has splits, it is still possible to change the commodity_scu (smallest fraction) of the account (ie we can move from 1/100 to 1/10). The existing splits are not adjusted to the new commodity_scu. Is it expected behavior ? There are a couple of ways of looking at that. The most accurate representation would be that SCU is for display only and all numbers should be maintained at the maximum possible precision to reduce rounding errors, but that's not always industry practice; some institutions round every transaction using a so-called banker's round and expect the results to even out over time. GnuCash's code is inconsistent in this regard: Some operations check the SCU and round to it, others don't. As part of the rewrite we should decide on a policy and make sure that we consistently apply it. ok - similarly the fraction traded in a commodity (non currency) can be changed even though accounts related to it have already splits that may use higher precision that the new fraction traded. Is it expected behavior ? That's a more general example, with the same answer. indeed - in the security editor, are symbol/abbreviation and display symbol the same field ? No, the latter is a recent change to allow users to select a different character for display depending on their local needs. For example, a Canadian might want $ to represent CAD and U$ for USD, while someone to the south might prefer the other way around. so it is only valid for currencies and not commodities ? because in gnucash 2.6.4, when I changed the symbol on a non currency, it sets it back to the symbol/abbreviation. On currencies, it adds a slot user_symbol with the symbol. I was wondering if there was not a set of characteristics of the accounts/commodity that are write once (ie, they are defined at the creation of the account/commodity but they can't be modified once they have other objects, like splits, relating to them). Is it more or less correct ? Perhaps there should be but the code doesn't work that way, nor does real life: Consider the decimalization of Pounds Sterling or of the US stock pricing. If we do adopt a policy that some properties should be immutable I think it should be absolute rather than dependent upon whether there are instances in the database. The latter choice would complicate the code for IMO little gain. yes indeed, simpler to say it is a write-once/never-change that some more complex pattern. However, as you pinpoint, it locks down the flexibility as we never know what can happen... Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Report wrapper to call python scripts?
Just a thought regarding the need for a python distribution for the python binding on Windows/OS X, would it be an option to build a single executable with the gnucash bindings (see http://www.orbitals.com/programs/pyexe.html or http://www.decalage.info/en/python/py2exe) ? This would give a complete control on the required python version/package distribution. And if the user is more knowledgeable re python, it could go with its own distribution (+ other relevant comment in this thread) ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
currency linked to a stock
Hello, There is no currency explicitly linked to a given stock (is this correct?). As a result, one can attach to a given stock multiple prices in multiple commodities. For instance, YHOO (which is traded in USD) could have a price in CAD if entered manually (in the price editor or through a transaction). When using the online download, one always get the correct currency. Shouldn't each security (that is not a currency) have its currency (like USD for YHOO) ? or is this a feature ? On a related topic, if I have an account with YHOO stock as a commodity (and so traded in USD), but that my default currency is CAD and that I have downloaded both the YHOO prices in USD and the exchange rate USD/CAD, can Gnucash convert the YHOO stock in CAD when displaying the Grand Total ? kr Sebastien ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: currency linked to a stock
On Yahoo! Finance, there are multiple symbols for Yahoo! Inc in function of the exchange (YHOO for Nasdaq, YHOO.BA for buenos aires, YHO.DE. For XETRA,...). Should all these stocks be the same commodity in GnuCash (with then multiples prices in function of the currency) ? Or should they be different commodities (with different namespaces) ? And if I have a brokerage account to trade stocks, can I buy the yahoo stock on Nasdaq and sell it back on XETRA ? Or should I be a bank/trader to be able to do that ? (I haven't gone farther than sell/buy stock to/from the same exchange for my personal use) I thought there would be different stocks in GnuCash and that a stock would have a single currency. Now, the example of the Cheddar is a bit stretched as it looks more similar to I buy a house in CAD and sell it back in USD (ie it could be considered as an asset/account and not as a commodity). If one was to manage import/export of goods in multiple currencies (ie not through an exchange), would it use commodities to do so in GnuCash (one commodity per type of cheese (or type of electronic material or type of clothes) ? On Wednesday, December 17, 2014, John Ralls jra...@ceridwen.us wrote: On Dec 17, 2014, at 1:28 PM, Sébastien de Menten sdemen...@gmail.com javascript:; wrote: Hello, There is no currency explicitly linked to a given stock (is this correct?). As a result, one can attach to a given stock multiple prices in multiple commodities. For instance, YHOO (which is traded in USD) could have a price in CAD if entered manually (in the price editor or through a transaction). When using the online download, one always get the correct currency. Shouldn't each security (that is not a currency) have its currency (like USD for YHOO) ? or is this a feature ? On a related topic, if I have an account with YHOO stock as a commodity (and so traded in USD), but that my default currency is CAD and that I have downloaded both the YHOO prices in USD and the exchange rate USD/CAD, can Gnucash convert the YHOO stock in CAD when displaying the Grand Total ? It’s a feature. While a particular stock exchange will price a stock traded on that exchange in the national currency, stocks are traded on many exchanges and privately, and those trades can be denominated in any exchange mechanism the two traders agree on. Aside from online quotes, there’s no difference to GnuCash between Yahoo Stock and a wheel of Cheddar cheese. You can easily imagine buying a wheel of cheese in Wisconsin for say $15 on behalf of a friend at home who pays you C$20 for it. It’s actually possible (though not easy) to do the same with Yahoo stock. ISTR there was a bug or a complaint here that stocks priced in foreign currencies don’t roll up properly into top-level accounts. It *should* work, but apparently doesn’t right now. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
need for KvpFrame vs /path/for/key in key/value store
Hello, I was wondering why there was a need for a KvpFrame type when the key was nevertheless holding the full path to the value, for example a Book may have the slot: options : a frame holding options/Accounts : a frame holding options/Accounts/Use Trading Accounts : a boolean If the names where just options : a frame holding Accounts : a frame holding Use Trading Accounts : a boolean then options/Accounts/Use Trading Accounts would be an hierachical path across several frames to end to a value. But as we have anyway options/Accounts/Use Trading Accounts : a boolean why do we need the frames options and options/Accounts as we already have the path/to/key that gives an hierarchical structure to the keys ? Is it due to an historical decision ? Is it still useful today ? kr sebastien ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: need for KvpFrame vs /path/for/key in key/value store
replying to myself :-) - in xml, the slots frame present an hierarchical structure as slot slot:keyoptions/slot:key slot:value type=frame slot slot:keyAccounts/slot:key slot:value type=frame slot slot:keyUse Trading Accounts/slot:key slot:value type=stringt/slot:value /slot /slot:value /slot /slot:value /slot - in sqlite, the key/value slots hold the full path to the slot like id obj_guid name slot_type 58 39fb62a42d731ddaa64ecd4daa764063 options 9 59 e51867d989899ba91314ef7c5c2e246b options/Budgeting 9 60 e51867d989899ba91314ef7c5c2e246b options/Accounts 9 61 7d781ad6895569f66447d74947e600be options/Accounts/Use Trading Accounts 4 With the sqlite type of representation, one could ponder the use of the KVP Frame object as the name includes the hierarchical relation. On Tue, Dec 16, 2014 at 8:36 PM, Sébastien de Menten sdemen...@gmail.com wrote: Hello, I was wondering why there was a need for a KvpFrame type when the key was nevertheless holding the full path to the value, for example a Book may have the slot: options : a frame holding options/Accounts : a frame holding options/Accounts/Use Trading Accounts : a boolean If the names where just options : a frame holding Accounts : a frame holding Use Trading Accounts : a boolean then options/Accounts/Use Trading Accounts would be an hierachical path across several frames to end to a value. But as we have anyway options/Accounts/Use Trading Accounts : a boolean why do we need the frames options and options/Accounts as we already have the path/to/key that gives an hierarchical structure to the keys ? Is it due to an historical decision ? Is it still useful today ? kr sebastien ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: python GnuCash interface to SQL backend
On Monday, November 17, 2014, Derek Atkins warl...@mit.edu wrote: 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. Yes indeed. Me first needs are a) to read a GnuCash boom from python and b) to create some new objects (accounts, commodities, transactions splits, prices). This is what is implemented and works today. Updating/deleting existing objects is delicate as is the creation of more complex business objects (relying on the kvp) - not in scope So I should have say that it is a CR (not UD) interface to GnuCash books. Sebastien ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: python GnuCash interface to SQL backend
On Saturday, November 15, 2014, Christian Stimming christ...@cstimming.de wrote: Dear Sébastien, I really try not to be rude, but a little bit it seems to me as if you don't accept no as an answer here. You asked whether the gnucash developers support an alternative SQL access layer written in python from scratch, and John's and other answers clearly said no. What else are you looking for? Hello Christian, I don't think I have asked the question you point here above but I admit I have asked a lot of other questions (to say the least ;-) ) and I got the answers of John and Derek right : they do not think it can be successful to write an external application/library that works directly on the SQL database due mainly to the complexity of the GnuCash engine (and how it handles/keeps the data in sync) John as already outlined many important aspects about our object model. In case you haven't see this so far, some current documentation is also here http://wiki.gnucash.org/wiki/C_API and the linked Entity-Relationship Diagram there, http://wiki.gnucash.org/wiki/images/8/86/Gnucash_erd.png . Thank you for the links (I had read these pages before starting working on the project and there were very useful). But let's just make this clear: You asked whether your idea would be endorsed and supported by us, and the answer was clearly a no. If you like to continue your idea, feel free to do so. But just don't repeatedly discuss here whether we want to change our answer (at this point in time). Thanks! As written here above, I have not asked this question. To recap, I could/can not find a satisfying solution to my needs (work on GnuCash books from python): - going the XML way (instead of SQL) has been suggested but suffers from all the drawbacks from the SQL way (data corruption) - using the official python binding is painful for me (swig/C code, install on windows) I have done in the summer a pure python package that worked for my needs. As this was very useful, I planned to make it more robust and release it. Before doing that I wanted to notify you/the core devs and get some advice, which I got thanks to the time John and Derek spent on this thread (and I can't be more grateful to them). I continue to work on piecash and it is going smoothly but I have been warned of the difficulties lying ahead. Kind regards Sebastien ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: python GnuCash interface to SQL backend
Hello John, I have put at this address https://github.com/sdementen/piecash/blob/master/docs/source/object_model.rst what I understood from the object model of GnuCash (schema/fields/invariants). I have also added some questions regarding the objects for which you may have the answer... (or these may be somewhere in GnuCash docs I could not find) I would be keen to get your opinion on this document. kind regards, Sebastien ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: python GnuCash interface to SQL backend
First of all, thank you John for taking the time to answer to this thread ! If you see GnuCash from the (limited) perspective of an editor for a Book document (as LibreOffice Writer is an editor for a ODT document), object persistence is central. And luckily we have both a very clean and well designed object model in GnuCash as well as standard persistence formats (xml, SQL and not an obscure binary format). I don’t share either opinion, especially about the object model in GnuCash. When talking about the object model, I am referring to the entities (Account, Book, Split, ...), their relation and attributes. And for most of the core objects (excluding company, invoice, ...) it is rather clean and efficient. Personnally, I think it could be a great basis for an open document format for this domain of application (better than QIF co). In terms of the implementation itself of the object model, the main things I see not that clean are: - KVP vs field representation - XXX_denom / XXX_num split (instead of using a Decimal type) But these two points should be hidden for the user/developper in python bindings (official or piecash). The GnuCash documentation states that the XML document can be used to get the GnuCash data in whatever other format (see Converting XML GnuCash File http://www.gnucash.org/docs/v2.6/C/gnucash-guide/appendixa_xmlconvert1.html) through XLST transformation and vice-versa (so generating a new/transformed gnucash XML file from a LibreOffice spreadsheet). No matter what the GnuCash documentation might say, only someone with a deep understanding of GnuCash could successfully create a correct GnuCash data file from a spreadsheet document using XSLT. I’m not familiar with LibreOffice’s ODS format, but I expect that it would take deep knowledge of that format to successfully extract useful data from it with XSLT as well. I agree that creating GnuCash file through XSLT is probably clause to be a nightmare ... that is why I quickly dropped the XML route (on ODS, I just took what was written in the GnuCash doc, and indeed interacting with such document require some library). PieCash (I like your name !) aims to fulfill exactly this purpose, no more, no less. As with the XLST transforms, it allows to do CRUD operations on the objects within a GnuCash Book. CRUD operations on a GnuCash database will corrupt it. The GnuCash schema is not normalized, and not all of the necessary data is stored in the table associated with the objects. CRUD operations is not to be taken as pure CRUD operations, there should always be in piecash a check that the set of objects is self-consistent (but this is really simple, obvious, natural constrains if one know a bit the GnuCash object model) Could you point me to 2 or 3 real case example we would nevertheless end up corrupting the database ? It would really help me to materialise this risk. With my practical experience with piecash (creating a full account tree structure and importing thousands of transactions from csv file), I haven't found any case of corruption (except when developing the API and having obvious bugs). Has this stance on the manipulation outside GnuCash of a GnuCash document evolved since it was written ? Would this still be supported after the C++ rewrite ? It isn’t supported now. It never has, and it is unlikely that it ever will be, even if we are able, after several development cycles, to actually migrate to a 3N database schema. There is too much logic that is encoded in the program and which cannot be portably encoded in a SQL database, to make that feasible. For piecash, there is no need for a 3N db schema and there is no need to write any logic in SQL ! It is through SQLAlchemy that we can handle/encapsulate the extra bit of logic (which is, as far as I am in the development of piecash and given piecash scope, rather limited). Nothing is done in SQL itself. All the rest is handled automatically thanks to the SQLAlchemy layer (link between objects, cascade delete, locking and transactions, generation of GUID key, …). Won’t work. SQLAlchemy can’t automatically generate a correct class from the schema nor can it derive a correct table description from the C headers. The table schema is exactly the only piece of code that needs to be written (piecash is in fact just that, table schemas with some metadata). I do not hope/expect/think to generate this code automatically from C headers (as SWIG does). You’ll get closer working with the XML schema. There’s a reasonably up-to-date version in src/doc/xml/gnucash-v2.rnc. As written here above, XML is not easy to work with (at least for me) and does not save me of anything you said before (corruption, etc). So, I admit, the main effort in this project consisted in writing for each entity (book, account, etc) the equivalent here above code as well as the relationships between entities. The later is done with a syntax
Re: python GnuCash interface to SQL backend
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. 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. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: python GnuCash interface to SQL backend
On Fri, Nov 14, 2014 at 3:31 AM, Derek Atkins warl...@mit.edu wrote: Sébastien de Menten sdemen...@gmail.com writes: Where could I find detailed documentation on the GnuCash engine (and the constrains/invariants GnuCash enforces) ? Or would there be some code/program to check a GnuCash file is sane/consistent ? Only in the implementation. There is no documentation per se on this, because we do not support modification of the database from outside the GnuCash APIs. This also allows us to change the underlying storage mechanisms without breaking things, because it's all abstracted. By re-implementing it you're basically binding yourself to a particular version of the database schema, which can (and will) change over time, requiring you to duplicate the effort already happening in the gnucash code. Moreover, you're also tied to a particular backend, which isn't very nice. Indeed, piecash is only applicable to the SQL backend and depends on the version of the SQL schema used by GnuCash. But as GnuCash is rather good at keeping backward compatibility, my fears are not so high in this respect (we can a minor changes but that is ok). I can add a check on the different rows of the VERSION table to ensure explicitly that the schema has not changed. A major rewrite of GnuCash and/or the SQL backend would require a major rewrite of piecash, but that's OK, we are talking about 500 SLOC. If you want to modify the gnucash database, you really should use the exported GnuCash APIs. If the current python bindings aren't pythonic enough for you, then I urge you to spend the time to fix that instead of reimplementing something that will absolutely break some time in the future. When it will break I cannot tell you, but I can assure you it WILL break at some point. I agree, it requires indeed to follow the evolution of GnuCash SQL schema. But these changes are well documented in the changelog. The official python bindings are C/SWIG based and are more complex to understand than the 500 SLOC of piecash. I have a preference to work with piecash even if I understand that it fragments the python bindings situation. But ok, I can't forbid myself to scratch this itch :-) kind regards, Sebastien ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: python GnuCash interface to SQL backend
On Friday, November 14, 2014, John Ralls jra...@ceridwen.us wrote: On Nov 14, 2014, at 4:28 AM, Sébastien de Menten sdemen...@gmail.com javascript:_e(%7B%7D,'cvml','sdemen...@gmail.com'); wrote: In terms of the implementation itself of the object model, the main things I see not that clean are: - KVP vs field representation - XXX_denom / XXX_num split (instead of using a Decimal type) But these two points should be hidden for the user/developper in python bindings (official or piecash). I experimented with the available decimal libraries over the summer. They’re mostly too slow and they don’t afford enough control over rounding to be sufficiently accurate for accounting use. The object model as it stands now has too much interdependence between classes, especially the transaction, split, account, and commodity classes. The implementation has a lot of When looking at the SQL/XML document, what would be the unneeded interdependencies ? The links between account-split-transaction looks meaningful to me. The links transaction-currency and account-commodity also. Is it the issues with the scu/denom/num that is cumbersome to handle (if there is a change in the scu of a currency, all splits related to it should be updated) ? Could you point me to 2 or 3 real case example we would nevertheless end up corrupting the database ? It would really help me to materialise this risk. With my practical experience with piecash (creating a full account tree structure and importing thousands of transactions from csv file), I haven't found any case of corruption (except when developing the API and having obvious bugs). I can’t provide concrete examples without doing an extensive code review of piecash, for which I have neither the time nor the inclination. Some obvious trouble spots include cross-commodity transactions, especially involving lots or trading accounts. Have you tested with bad data to see if piecash rejects it? Did you thoroughly analyze the ways that bad data could be created and ensure that you have test cases proving that piecash rejects all of them? Well, at first, I wanted to have a simple way to extract data out of GnuCash (a read-only mode). This was easy to do with SQL alchemy and is safe. Afterwards, I wanted to be able to modify a GnuCash book knowing what I was doing (ie being cautious to not create inconsistent objects. This was also ok (as said, I have used piecash to create automatically a complex account structure from an excel file and to import thousands of records without errors). Next is the ability to ensure consistency checks/error detection when the user does changes. This is the less mature part and I hear well your warnings about the complexity of this part. For piecash, there is no need for a 3N db schema and there is no need to write any logic in SQL ! It is through SQLAlchemy that we can handle/encapsulate the extra bit of logic (which is, as far as I am in the development of piecash and given piecash scope, rather limited). Nothing is done in SQL itself. I have trouble believing that an ORM will generate a correct implementation with a non-normal schema. In piecash, the ORM does not generate the SQL schema as it already exists (it is the one defined by GnuCash). It just maps the existing schema (that needs to be redescribed in python) to python objects transparently handling type conversion, transactions, guids, relationships, etc The table schema is exactly the only piece of code that needs to be written (piecash is in fact just that, table schemas with some metadata). I do not hope/expect/think to generate this code automatically from C headers (as SWIG does). You’re not being consistent. Are you using SQLAlchemy as an ORM or simply as a SQL abstraction layer? You said above that nothing is done in SQL, and earlier that you are doing consistency checks, but here you’re saying that all you’ve written is a table-schema, which would imply that you’re relying on the database to do all of the work. I am using sqlalchemy as a mapper and as a session manager (unit of work pattern). Nothing is done in SQL (meaning I do not write SQL queries nor SQL stored procedures). A cascade delete constrain (if I remove a transaction, all related splits are automatically deleted) is also managed by SA. So I am essentially writing a mapping and then adding some methods to either create objects in a consistent way (like having a function create_transaction(from_acc, to_acc, amount, date, description) that create always correct objects) or to check objects are consistent before commit (this is not yet done) You’ll get closer working with the XML schema. There’s a reasonably up-to-date version in src/doc/xml/gnucash-v2.rnc. As written here above, XML is not easy to work with (at least for me) and does not save me of anything you said before (corruption, etc). Sounds like a learning opportunity. But will this save me
Re: python GnuCash interface to SQL backend
On Wednesday, November 12, 2014, John Ralls jra...@ceridwen.us wrote: On Nov 11, 2014, at 1:10 PM, Sébastien de Menten sdemen...@gmail.com javascript:; wrote: I would be genuinely interested to have more specific documentation on the risks of going the SQL way. There's nothing wrong with reading the database to generate reports. That is indeed easier for many people via SQL query than writing custom report plugins in Scheme. It may also be easier to go with the SQL than with the std python binding for reporting but also to change the GnuCash book. The risk of writing to the database outside of GnuCash, whether in SQL or XML, is that unless you are very careful and have a deep understanding of how GnuCash works that you will irretrievably corrupt your accounting data. There is no business logic encoded in the SQL database, so your code must replicate the GnuCsah engine code to ensure that all required fields are computed and stored correctly. Much of GnuCash is neither straightforward nor obvious and some critical data are stored outside of the primary tables, usually to preserve backward compatibility with previous versions. Regards, John Ralls I have mainly used the basic objects from GnuCash required for basic personal finance (so no invoice, no budget, ...) and did not found any issues while handling lot of accounts/transactions/splits and stock prices. I had the impression that GnuCash does indeed calculations when the book is opened but that it does not save them in the SQL backend. Hence, if we access the book when it's not opened by GnuCash at the same time, risks are quite reduced, would this be a wrong impression ? Where could I find detailed documentation on the GnuCash engine (and the constrains/invariants GnuCash enforces) ? Or would there be some code/program to check a GnuCash file is sane/consistent ? Regards Sebastien ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: python GnuCash interface to SQL backend
On Thursday, November 13, 2014, John Ralls jra...@ceridwen.us wrote: On Nov 12, 2014, at 12:08 PM, Sébastien de Menten sdemen...@gmail.com javascript:_e(%7B%7D,'cvml','sdemen...@gmail.com'); wrote: On Wednesday, November 12, 2014, John Ralls jra...@ceridwen.us javascript:_e(%7B%7D,'cvml','jra...@ceridwen.us'); wrote: On Nov 11, 2014, at 1:10 PM, Sébastien de Menten sdemen...@gmail.com wrote: I would be genuinely interested to have more specific documentation on the risks of going the SQL way. There's nothing wrong with reading the database to generate reports. That is indeed easier for many people via SQL query than writing custom report plugins in Scheme. It may also be easier to go with the SQL than with the std python binding for reporting but also to change the GnuCash book. It might be, but I doubt it. You won’t be able to implement the business logic in SQL alone. The python interface uses SQLAlchemy (an ORM) only to handle the backend (retrieve and save objects), all business logic is in the python code. For instance, when creating a transaction and the related splits, it is the python code that ensures the business logic (for instance that the sum of the splits = 0). This is close to what GnuCash does. Moreover, there are some basic SQL integrity constrains (we cannot remove a split without removing the related transaction) that are added in the ORM layer as they do not exist in the SQL backend. I have mainly used the basic objects from GnuCash required for basic personal finance (so no invoice, no budget, ...) and did not found any issues while handling lot of accounts/transactions/splits and stock prices. I had the impression that GnuCash does indeed calculations when the book is opened but that it does not save them in the SQL backend. Hence, if we access the book when it's not opened by GnuCash at the same time, risks are quite reduced, would this be a wrong impression ? I’m not sure I follow you about calculations when the book is opened that aren’t saved. I was thinking about temporary results/cached calculations/etc that are not saved to the back ends (if there are any). With the SQL backend, everything is written back to the database when a change is committed, so the *results* of the calculations are immediately saved. What GnuCash doesn’t do is *read* the database after the initial load, nor does it use any database concurrency control, so there are two potential ways to screw things up with two programs (even two instances of GnuCash) using the same database: A change made by one instance could be overwritten by a change made in the other or, much worse, the two instances could try writing the same records at the same time, corrupting those records. Indeed, if GnuCash has opened the file and is using it (ie there is a lock in the table gnc_lock), we are almost 100% sure to have the issues you mentions if we change the file in parallel through SQL. There is a check in pyscash that raises an exception in this case (it can be overruled but at user's own risk. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: python GnuCash interface to SQL backend
On 2014-11-13 19:25, John Ralls wrote:
On Nov 13, 2014, at 9:31 AM, Sébastien de Menten sdemen...@gmail.com wrote:
Indeed, it may be worth to explain what are the goals (and the limits).
I have tried to use the official python bindings and had the following issues:
- need swig + compilations to make them work = pyscash is pure python and has
only sqlalchemy as main dependency (which is rather supported/standard package)
- python binding is a mapping if C API with a thin layer python friendly layer
= I do not find the resulting python scripts very pythonic
[...]
So, to sum up, goals of pyscash :
- easy installation as pure python module (no compilation, no swig, ...)
- easy to contribute as pure python and based on de facto standard ORM for SQL
in python (sql alchemy)
- pythonic implementation by leveraging SQL Alchemy features (transparent
handling of guid, free commit/rollback/transaction support, automatic
parent-children relation handling, etc)
- pythonic interface for CRUD operations on a GnuCash Book
The last point is important as the goal is not at all to reimplement the whole
GnuCash engine but only to be able to manipulate (CRUD operations) the
different GnuCash entities (book, account, currency, etc) in an easy pythonic
way.
For instance, I do not plan to reimplement functions like GetBalance,
GetReconciledBalance, GetPresentBalanceInCurrency, GetAccountBalance, etc
Is the goal of the project clearer ?
Do you see complexities in reimplementing the pure CRUD operations (except the
basic complexities of leaving a GnuCash book in a consistent status) ?
On the name issue, you are definitely right ! I had in mind a pie-ess-cash
pronounciation (the S for SQL) as pygnucash was already taken. Any suggestion ?
pysacash (python sqlalchemy gnucash interface) ? or is it even worse :-) ?
kind regards,
Sebastien
ps: and thank you for clarifying the announce on the user mailing list ! I
should have thought about that myself to avoid confusion…
Sébastien,
Please remember to copy the list on all replies.
The goal of the project is clearer but is in my mind severely misguided. Object
persistence is always a side effect of a non-trivial program, and GnuCash is a
non-trivial program.
If you see GnuCash from the (limited) perspective of an editor for a
Book document (as LibreOffice Writer is an editor for a ODT document),
object persistence is central. And luckily we have both a very clean and
well designed object model in GnuCash as well as standard persistence
formats (xml, SQL and not an obscure binary format).
The GnuCash documentation states that the XML document can be used to
get the GnuCash data in whatever other format (see Converting XML
GnuCash File
http://www.gnucash.org/docs/v2.6/C/gnucash-guide/appendixa_xmlconvert1.html)
through XLST transformation and vice-versa (so generating a
new/transformed gnucash XML file from a LibreOffice spreadsheet).
PieCash (I like your name !) aims to fulfill exactly this purpose, no
more, no less. As with the XLST transforms, it allows to do CRUD
operations on the objects within a GnuCash Book.
Has this stance on the manipulation outside GnuCash of a GnuCash
document evolved since it was written ? Would this still be supported
after the C++ rewrite ?
your complaint about the python bindings is that they’re not pythonic I think
that your efforts would be better spent improving that. It should become easier
as we progress through the C++ rewrite which will produce a much more
object-oriented architecture where that’s appropriate. That said, it’s also
worth noting that C++ is a far more versatile language than either C or Python
in that it supports generic and functional programming as well as the
structured and OO paradigms that Python supports. In moving away from GObject
we’ll also be enforcing type safety much more rigorously. Since that’s a
notorious weakness (though casual hackers think it’s a feature) of Python,
having thin Python wrappers around C++ objects will provide for much safer
Python add ons than does the current code base.
The python binding are not pure python bindings (and will probably never
be as they should interface C or C++ code). This makes them not easily
accessible on Windows platforms (complexity in compilation) and more
complex to hack (for non C/C++ programmers). However, they offer the
ability to call any function of the engine and to be independent of the
backend (XML, SQL,...) as long as it is interfaced so may be the only
solution in some cases.
On the other side, PieCash is pure python. The code required to
interface an entity is almost trivial. For instance, the full interface
to the Commodity entity is
class Commodity(DeclarativeBaseGuid):
__tablename__ = 'commodities'
__table_args__ = {}
# column definitions
cusip = Column('cusip', TEXT(length=2048))
fraction = Column('fraction', INTEGER(), nullable=False
python GnuCash interface to SQL backend
Hello, After trying multiple times to work with GnuCash from python (via xml, via the python bindings, via sql), I finally had a try to use SQLAlchemy to handle the GnuCash Books saved through the SQL backend (sqlite3 and postgres). I have a release on PyPI the package pyscash installable through 'pip install pyscash' (see some raw documentation on https://github.com/sdementen/pyscash). It is 'alpha' quality. While it opens by default the Book in read only mode to be able to do reporting or extract data from a GnuCash Book, I also succeeded in doing more elaborate scripts that change a Book : creating new accounts/sub-accounts, creating new transactions, uploading quotes for stocks, etc. I read that the SQL backend is just a backend to save the data and that GnuCash is not a DB application and that the preferred way to program GnuCash in python is through the python bindings. However, I found it much easier to work with this pyscash package, at least as long as it is done offline (i.e. not modifying a Book that is at the same time opened by GnuCash). I would be genuinely interested to have more specific documentation on the risks of going the SQL way. Sebastien ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
