Re: Reports

[Martin Blais]

On Mon, Apr 30, 2018 at 4:53 PM,  wrote:

> Sweet, thanks!
>
- For my holding, I need to generate tax reports and income and
>>> balancesheets at the end of the year. The latter ones are present, but a
>>> bit bare (no dates on the page, no formatting for example).
>>
>> Do you mean a list of trades? Trades (i.e., "reductions and their
>> corresponding augmentations") are available as metadata. I'm not sure if I
>> ever bothered creating a report for them, but they're available from the
>> stream of transactions, it should be easy to write a script to list them
>> out in your favorite format.
>>
>
> No, I meant the amount of tax I have posted to an account in a certain
> period. But I saw you also added a QUARTER function, which helps a lot with
> that!
>

For that you can just select sum(postings) where date >= ... and date < ...


On Monday, 30 April 2018 05:42:25 UTC+2, Martin Blais wrote:
>>
>> hg update, I've added a couple of things:
>> - A POSSIGN() function, which can be used to straighten the sign based on
>> the account associated with an amount. You can use it like this:
>>
>>   bean-query $L "select account, sum(possign(position, account)) where
>> account ~ 'Liabilities:' group by 1"
>>
>> - A NEG() function, which can be used to negate the value of an Amount,
>> Position or Inventory.
>>
>> This works as a temporary fix, but it isn't great. There isn't real
>> arithmetic on all field types. (The SQL shell was developed in a weekend a
>> long time ago and has become a bit of a dumping ground for ideas and has
>> overserved its time. It needs a complete rewrite from scratch, for many
>> reasons. I want to do that eventually, but before then, merge all the
>> pending pull requests and fix some of the more important bugs.) In any
>> case, I hope this helps,
>>
>>
>>
>>
>> On Sun, Apr 29, 2018 at 7:38 PM, Martin Blais  wrote:
>>
>>> On Sun, Apr 29, 2018 at 6:10 AM,  wrote:
>>>
 I have a couple use cases for "reports", that I haven't found an easy
 way to generate yet.

 - For my holding, I need to generate tax reports and income and
 balancesheets at the end of the year. The latter ones are present, but a
 bit bare (no dates on the page, no formatting for example).

>>>
>>> Do you mean a list of trades? Trades (i.e., "reductions and their
>>> corresponding augmentations") are available as metadata. I'm not sure if I
>>> ever bothered creating a report for them, but they're available from the
>>> stream of transactions, it should be easy to write a script to list them
>>> out in your favorite format.
>>>
>>>
>>>
 - For a group of friends, I manage the common account. I've set them up
 as Liabilities, as that's what the account owns to them. But now all
 balances are inverted, which makes it a bit weird for them. I'd like to
 just output the Liabilities accounts with balance * -1. (I tried:

 SELECT account, sum(position) * -1 WHERE account ~ 'Liabilities:' GROUP BY 
 account;

 but that results in "TypeError: descriptor '__mul__' requires a
 'decimal.Decimal' object but received a 'Inventory'
 ". I guess I could export to csv, open in Excel and just add this, but
 that's cheating :). Ideally I'd add a page to Fava with this "report", but
 haven't found a way yet.)

>>>
>>> You just need an operator to negate an inventory object. Let me make you
>>> one.
>>> In fact, better might be a function which switches the signs based on
>>> the account type, e.g. something like this:
>>>
>>>   SELECT account, sum(position) * account_sign(account) ..
>>>
>>> ACCOUNT_SIGN(account) would take the value -1 for Liabilities, Equity
>>> and Income, and +1 for the others.
>>> I can add those later.
>>>
>>>
>>>
>>>

 How do you all generate your (tax) reports and in what format do you
 save them?

>>>
>>> Tax reports? I use TurboTax. I kick off bean-web with a restricted
>>> period for that year and eyeball the numbers from the income statement.
>>> Most of the actual input is automated from imported 1099-R's.
>>>
>>>
>>>
>>>

 Regards,


 Tino


 On Sunday, 1 April 2018 07:53:42 UTC+2, Martin Blais wrote:
>
> How many people here use bean-report as their main way to generate
> data from Beancount?
> How many use bean-web?
> Does anybody still care about bean-web now that Fava exists?
>
> Also... is it possible to bean-bake Fava (or some equivalent creation
> of a static version for sharing)?
>
> Any input appreciated,
>
>
> (Reason I'm asking is: I'm thinking about
> - rewriting the query engine to something more powerful and general,
> and promoting it from experimental and somewhat flaky to the main way of
> getting data out
> - rewriting bean-web to be a dumber, more generic web interface that
> basically renders SQL queries (using the new query engine) without any
> special treatment (just tables and tree-tab

Re: Reports

[tinodb]

Sweet, thanks!

- For my holding, I need to generate tax reports and income and 
>> balancesheets at the end of the year. The latter ones are present, but a 
>> bit bare (no dates on the page, no formatting for example).
>
> Do you mean a list of trades? Trades (i.e., "reductions and their 
> corresponding augmentations") are available as metadata. I'm not sure if I 
> ever bothered creating a report for them, but they're available from the 
> stream of transactions, it should be easy to write a script to list them 
> out in your favorite format.
>

No, I meant the amount of tax I have posted to an account in a certain 
period. But I saw you also added a QUARTER function, which helps a lot with 
that!


On Monday, 30 April 2018 05:42:25 UTC+2, Martin Blais wrote:
>
> hg update, I've added a couple of things:
> - A POSSIGN() function, which can be used to straighten the sign based on 
> the account associated with an amount. You can use it like this:
>
>   bean-query $L "select account, sum(possign(position, account)) where 
> account ~ 'Liabilities:' group by 1"
>
> - A NEG() function, which can be used to negate the value of an Amount, 
> Position or Inventory.
>
> This works as a temporary fix, but it isn't great. There isn't real 
> arithmetic on all field types. (The SQL shell was developed in a weekend a 
> long time ago and has become a bit of a dumping ground for ideas and has 
> overserved its time. It needs a complete rewrite from scratch, for many 
> reasons. I want to do that eventually, but before then, merge all the 
> pending pull requests and fix some of the more important bugs.) In any 
> case, I hope this helps,
>
>
>
>
> On Sun, Apr 29, 2018 at 7:38 PM, Martin Blais  > wrote:
>
>> On Sun, Apr 29, 2018 at 6:10 AM, > wrote:
>>
>>> I have a couple use cases for "reports", that I haven't found an easy 
>>> way to generate yet.
>>>
>>> - For my holding, I need to generate tax reports and income and 
>>> balancesheets at the end of the year. The latter ones are present, but a 
>>> bit bare (no dates on the page, no formatting for example).
>>>
>>
>> Do you mean a list of trades? Trades (i.e., "reductions and their 
>> corresponding augmentations") are available as metadata. I'm not sure if I 
>> ever bothered creating a report for them, but they're available from the 
>> stream of transactions, it should be easy to write a script to list them 
>> out in your favorite format.
>>
>>  
>>
>>> - For a group of friends, I manage the common account. I've set them up 
>>> as Liabilities, as that's what the account owns to them. But now all 
>>> balances are inverted, which makes it a bit weird for them. I'd like to 
>>> just output the Liabilities accounts with balance * -1. (I tried: 
>>>
>>> SELECT account, sum(position) * -1 WHERE account ~ 'Liabilities:' GROUP BY 
>>> account;
>>>
>>> but that results in "TypeError: descriptor '__mul__' requires a 
>>> 'decimal.Decimal' object but received a 'Inventory'
>>> ". I guess I could export to csv, open in Excel and just add this, but 
>>> that's cheating :). Ideally I'd add a page to Fava with this "report", but 
>>> haven't found a way yet.)
>>>
>>
>> You just need an operator to negate an inventory object. Let me make you 
>> one.
>> In fact, better might be a function which switches the signs based on the 
>> account type, e.g. something like this:
>>
>>   SELECT account, sum(position) * account_sign(account) ..
>>
>> ACCOUNT_SIGN(account) would take the value -1 for Liabilities, Equity and 
>> Income, and +1 for the others.
>> I can add those later.
>>
>>
>>  
>>
>>>
>>> How do you all generate your (tax) reports and in what format do you 
>>> save them?
>>>
>>
>> Tax reports? I use TurboTax. I kick off bean-web with a restricted period 
>> for that year and eyeball the numbers from the income statement. Most of 
>> the actual input is automated from imported 1099-R's.
>>
>>
>>  
>>
>>>
>>> Regards,
>>>
>>>
>>> Tino
>>>
>>>
>>> On Sunday, 1 April 2018 07:53:42 UTC+2, Martin Blais wrote:

 How many people here use bean-report as their main way to generate data 
 from Beancount?
 How many use bean-web?
 Does anybody still care about bean-web now that Fava exists?

 Also... is it possible to bean-bake Fava (or some equivalent creation 
 of a static version for sharing)?

 Any input appreciated,


 (Reason I'm asking is: I'm thinking about
 - rewriting the query engine to something more powerful and general, 
 and promoting it from experimental and somewhat flaky to the main way of 
 getting data out
 - rewriting bean-web to be a dumber, more generic web interface that 
 basically renders SQL queries (using the new query engine) without any 
 special treatment (just tables and tree-tables)
 - deleting bean-reports and all of beancount/reports, or replacing most 
 of it by SQL queries
 - in the process deleting the Holdings code
 Basically, I think that with a slig

Re: Reports

[Martin Blais]

hg update, I've added a couple of things:
- A POSSIGN() function, which can be used to straighten the sign based on
the account associated with an amount. You can use it like this:

  bean-query $L "select account, sum(possign(position, account)) where
account ~ 'Liabilities:' group by 1"

- A NEG() function, which can be used to negate the value of an Amount,
Position or Inventory.

This works as a temporary fix, but it isn't great. There isn't real
arithmetic on all field types. (The SQL shell was developed in a weekend a
long time ago and has become a bit of a dumping ground for ideas and has
overserved its time. It needs a complete rewrite from scratch, for many
reasons. I want to do that eventually, but before then, merge all the
pending pull requests and fix some of the more important bugs.) In any
case, I hope this helps,




On Sun, Apr 29, 2018 at 7:38 PM, Martin Blais  wrote:

> On Sun, Apr 29, 2018 at 6:10 AM,  wrote:
>
>> I have a couple use cases for "reports", that I haven't found an easy way
>> to generate yet.
>>
>> - For my holding, I need to generate tax reports and income and
>> balancesheets at the end of the year. The latter ones are present, but a
>> bit bare (no dates on the page, no formatting for example).
>>
>
> Do you mean a list of trades? Trades (i.e., "reductions and their
> corresponding augmentations") are available as metadata. I'm not sure if I
> ever bothered creating a report for them, but they're available from the
> stream of transactions, it should be easy to write a script to list them
> out in your favorite format.
>
>
>
>> - For a group of friends, I manage the common account. I've set them up
>> as Liabilities, as that's what the account owns to them. But now all
>> balances are inverted, which makes it a bit weird for them. I'd like to
>> just output the Liabilities accounts with balance * -1. (I tried:
>>
>> SELECT account, sum(position) * -1 WHERE account ~ 'Liabilities:' GROUP BY 
>> account;
>>
>> but that results in "TypeError: descriptor '__mul__' requires a
>> 'decimal.Decimal' object but received a 'Inventory'
>> ". I guess I could export to csv, open in Excel and just add this, but
>> that's cheating :). Ideally I'd add a page to Fava with this "report", but
>> haven't found a way yet.)
>>
>
> You just need an operator to negate an inventory object. Let me make you
> one.
> In fact, better might be a function which switches the signs based on the
> account type, e.g. something like this:
>
>   SELECT account, sum(position) * account_sign(account) ..
>
> ACCOUNT_SIGN(account) would take the value -1 for Liabilities, Equity and
> Income, and +1 for the others.
> I can add those later.
>
>
>
>
>>
>> How do you all generate your (tax) reports and in what format do you save
>> them?
>>
>
> Tax reports? I use TurboTax. I kick off bean-web with a restricted period
> for that year and eyeball the numbers from the income statement. Most of
> the actual input is automated from imported 1099-R's.
>
>
>
>
>>
>> Regards,
>>
>>
>> Tino
>>
>>
>> On Sunday, 1 April 2018 07:53:42 UTC+2, Martin Blais wrote:
>>>
>>> How many people here use bean-report as their main way to generate data
>>> from Beancount?
>>> How many use bean-web?
>>> Does anybody still care about bean-web now that Fava exists?
>>>
>>> Also... is it possible to bean-bake Fava (or some equivalent creation of
>>> a static version for sharing)?
>>>
>>> Any input appreciated,
>>>
>>>
>>> (Reason I'm asking is: I'm thinking about
>>> - rewriting the query engine to something more powerful and general, and
>>> promoting it from experimental and somewhat flaky to the main way of
>>> getting data out
>>> - rewriting bean-web to be a dumber, more generic web interface that
>>> basically renders SQL queries (using the new query engine) without any
>>> special treatment (just tables and tree-tables)
>>> - deleting bean-reports and all of beancount/reports, or replacing most
>>> of it by SQL queries
>>> - in the process deleting the Holdings code
>>> Basically, I think that with a slightly improved query engine I could
>>> delete a ton of code without removing functionality at all.)
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "Beancount" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beancount+unsubscr...@googlegroups.com.
>> To post to this group, send email to beancount@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/beancount/da245774-db4e-4e44-ba34-84e5c4bff222%40googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an ema

Re: Reports

[Martin Blais]

On Sun, Apr 29, 2018 at 6:10 AM,  wrote:

> I have a couple use cases for "reports", that I haven't found an easy way
> to generate yet.
>
> - For my holding, I need to generate tax reports and income and
> balancesheets at the end of the year. The latter ones are present, but a
> bit bare (no dates on the page, no formatting for example).
>

Do you mean a list of trades? Trades (i.e., "reductions and their
corresponding augmentations") are available as metadata. I'm not sure if I
ever bothered creating a report for them, but they're available from the
stream of transactions, it should be easy to write a script to list them
out in your favorite format.



> - For a group of friends, I manage the common account. I've set them up as
> Liabilities, as that's what the account owns to them. But now all balances
> are inverted, which makes it a bit weird for them. I'd like to just output
> the Liabilities accounts with balance * -1. (I tried:
>
> SELECT account, sum(position) * -1 WHERE account ~ 'Liabilities:' GROUP BY 
> account;
>
> but that results in "TypeError: descriptor '__mul__' requires a
> 'decimal.Decimal' object but received a 'Inventory'
> ". I guess I could export to csv, open in Excel and just add this, but
> that's cheating :). Ideally I'd add a page to Fava with this "report", but
> haven't found a way yet.)
>

You just need an operator to negate an inventory object. Let me make you
one.
In fact, better might be a function which switches the signs based on the
account type, e.g. something like this:

  SELECT account, sum(position) * account_sign(account) ..

ACCOUNT_SIGN(account) would take the value -1 for Liabilities, Equity and
Income, and +1 for the others.
I can add those later.




>
> How do you all generate your (tax) reports and in what format do you save
> them?
>

Tax reports? I use TurboTax. I kick off bean-web with a restricted period
for that year and eyeball the numbers from the income statement. Most of
the actual input is automated from imported 1099-R's.




>
> Regards,
>
>
> Tino
>
>
> On Sunday, 1 April 2018 07:53:42 UTC+2, Martin Blais wrote:
>>
>> How many people here use bean-report as their main way to generate data
>> from Beancount?
>> How many use bean-web?
>> Does anybody still care about bean-web now that Fava exists?
>>
>> Also... is it possible to bean-bake Fava (or some equivalent creation of
>> a static version for sharing)?
>>
>> Any input appreciated,
>>
>>
>> (Reason I'm asking is: I'm thinking about
>> - rewriting the query engine to something more powerful and general, and
>> promoting it from experimental and somewhat flaky to the main way of
>> getting data out
>> - rewriting bean-web to be a dumber, more generic web interface that
>> basically renders SQL queries (using the new query engine) without any
>> special treatment (just tables and tree-tables)
>> - deleting bean-reports and all of beancount/reports, or replacing most
>> of it by SQL queries
>> - in the process deleting the Holdings code
>> Basically, I think that with a slightly improved query engine I could
>> delete a ton of code without removing functionality at all.)
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Beancount" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beancount+unsubscr...@googlegroups.com.
> To post to this group, send email to beancount@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beancount/da245774-db4e-4e44-ba34-84e5c4bff222%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beancount+unsubscr...@googlegroups.com.
To post to this group, send email to beancount@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beancount/CAK21%2BhOaC7%3DH23OXXPWAQWy5YyqrXrFBq3KX_Y0d5GVQ8vcXsA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Reports

[tinodb]

I have a couple use cases for "reports", that I haven't found an easy way 
to generate yet.

- For my holding, I need to generate tax reports and income and 
balancesheets at the end of the year. The latter ones are present, but a 
bit bare (no dates on the page, no formatting for example).
- For a group of friends, I manage the common account. I've set them up as 
Liabilities, as that's what the account owns to them. But now all balances 
are inverted, which makes it a bit weird for them. I'd like to just output 
the Liabilities accounts with balance * -1. (I tried: 

SELECT account, sum(position) * -1 WHERE account ~ 'Liabilities:' GROUP BY 
account;

but that results in "TypeError: descriptor '__mul__' requires a 
'decimal.Decimal' object but received a 'Inventory'
". I guess I could export to csv, open in Excel and just add this, but 
that's cheating :). Ideally I'd add a page to Fava with this "report", but 
haven't found a way yet.)

How do you all generate your (tax) reports and in what format do you save 
them?

Regards,


Tino

On Sunday, 1 April 2018 07:53:42 UTC+2, Martin Blais wrote:
>
> How many people here use bean-report as their main way to generate data 
> from Beancount?
> How many use bean-web?
> Does anybody still care about bean-web now that Fava exists?
>
> Also... is it possible to bean-bake Fava (or some equivalent creation of a 
> static version for sharing)?
>
> Any input appreciated,
>
>
> (Reason I'm asking is: I'm thinking about
> - rewriting the query engine to something more powerful and general, and 
> promoting it from experimental and somewhat flaky to the main way of 
> getting data out
> - rewriting bean-web to be a dumber, more generic web interface that 
> basically renders SQL queries (using the new query engine) without any 
> special treatment (just tables and tree-tables)
> - deleting bean-reports and all of beancount/reports, or replacing most of 
> it by SQL queries
> - in the process deleting the Holdings code
> Basically, I think that with a slightly improved query engine I could 
> delete a ton of code without removing functionality at all.)
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beancount+unsubscr...@googlegroups.com.
To post to this group, send email to beancount@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beancount/da245774-db4e-4e44-ba34-84e5c4bff222%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Reports

[Martin Blais]

On Sat, Apr 14, 2018 at 6:36 PM, Vivek Gani  wrote:

> Throwing my two cents in, I'm a newbie at a point where I'm starting to
> have an import workflow down and starting to approach writing custom
> reports. I've been using fava more and it was a selling point (along with
> some other beancount features) for me at first in using it over ledger. I
> haven't really used bean-web yet, and only recently started playing with
> bean-query.
>
> > How many people here use bean-report as their main way to generate data
> from Beancount?
>
> Might be digressing, but I'm confused about the philosophy behind plugins,
> custom reports, and queries. Is the convention that users use/write plugins
> such that the standard reports in bean-report provide what most need? Was
> there ever a idea of a 'reports' directory (akin to 'importers')
> convention for additional reports that would then appear under bean-report
> or fava -- or are additional reports just supposed to be written/executed
> separately (as seen in some of the scripts in the 'experiments' folder)?
>

Here's a brief history:
When I first wrote this I wrote these custom reports.
Then I wrote a web client to render all these reports from a single place.
(They can also be invoked from the command-line, but not all output formats
are supported, it's not nice in that way.)
Then I wrote an experimental SQL query client, which grew over time.

At this point, we realize that you can do everything with the SQL client,
so I'd like to replace all the custom reports by SQL queries (after writing
a new version of the SQL query client, lots of ideas were issued from the
first version to make a better one) and remove the custom reporting code
eventually (and deprecate bean-web in favor of Fava).


Asking as my intial glance into reports.py (in beancount) and the 'REPORTS'
> array in application.py (in fava) are initially leading me to think that if
> one wants to add a report one keeps a personal branch of either project -
> wondering if there'd be interest in having something like a 'class
> ConfigReporterMixin' if the output from a report becomes more generic.
>

You will always be able to write custom things on top of the API, but I'd
like to eventually delete the current custom reports code that lives in
Beancount, if it can be replaced by equivalent queries.




-Vivek
>
> (Also, I'm nine days early, but happy tenth anniversary to beancount on
> the 'initial import' commit!)
>

Thank you!




>
>
>
> On Saturday, March 31, 2018 at 10:53:42 PM UTC-7, Martin Blais wrote:
>>
>> How many people here use bean-report as their main way to generate data
>> from Beancount?
>> How many use bean-web?
>> Does anybody still care about bean-web now that Fava exists?
>>
>> Also... is it possible to bean-bake Fava (or some equivalent creation of
>> a static version for sharing)?
>>
>> Any input appreciated,
>>
>>
>> (Reason I'm asking is: I'm thinking about
>> - rewriting the query engine to something more powerful and general, and
>> promoting it from experimental and somewhat flaky to the main way of
>> getting data out
>> - rewriting bean-web to be a dumber, more generic web interface that
>> basically renders SQL queries (using the new query engine) without any
>> special treatment (just tables and tree-tables)
>> - deleting bean-reports and all of beancount/reports, or replacing most
>> of it by SQL queries
>> - in the process deleting the Holdings code
>> Basically, I think that with a slightly improved query engine I could
>> delete a ton of code without removing functionality at all.)
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Beancount" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beancount+unsubscr...@googlegroups.com.
> To post to this group, send email to beancount@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beancount/fc515ea4-eb5b-4d25-84a9-d385022d3370%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beancount+unsubscr...@googlegroups.com.
To post to this group, send email to beancount@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beancount/CAK21%2BhPmjGz5bjTHB6daVm6t%3DpEqKBEuM92R%3D5iT7a%2BWs4c9BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Reports

[Vivek Gani]

Throwing my two cents in, I'm a newbie at a point where I'm starting to 
have an import workflow down and starting to approach writing custom 
reports. I've been using fava more and it was a selling point (along with 
some other beancount features) for me at first in using it over ledger. I 
haven't really used bean-web yet, and only recently started playing with 
bean-query. 

> How many people here use bean-report as their main way to generate data 
from Beancount?

Might be digressing, but I'm confused about the philosophy behind plugins, 
custom reports, and queries. Is the convention that users use/write plugins 
such that the standard reports in bean-report provide what most need? Was 
there ever a idea of a 'reports' directory (akin to 'importers')  
convention for additional reports that would then appear under bean-report 
or fava -- or are additional reports just supposed to be written/executed 
separately (as seen in some of the scripts in the 'experiments' folder)? 

Asking as my intial glance into reports.py (in beancount) and the 'REPORTS' 
array in application.py (in fava) are initially leading me to think that if 
one wants to add a report one keeps a personal branch of either project - 
wondering if there'd be interest in having something like a 'class 
ConfigReporterMixin' if the output from a report becomes more generic. 

-Vivek

(Also, I'm nine days early, but happy tenth anniversary to beancount on the 
'initial import' commit!)


On Saturday, March 31, 2018 at 10:53:42 PM UTC-7, Martin Blais wrote:
>
> How many people here use bean-report as their main way to generate data 
> from Beancount?
> How many use bean-web?
> Does anybody still care about bean-web now that Fava exists?
>
> Also... is it possible to bean-bake Fava (or some equivalent creation of a 
> static version for sharing)?
>
> Any input appreciated,
>
>
> (Reason I'm asking is: I'm thinking about
> - rewriting the query engine to something more powerful and general, and 
> promoting it from experimental and somewhat flaky to the main way of 
> getting data out
> - rewriting bean-web to be a dumber, more generic web interface that 
> basically renders SQL queries (using the new query engine) without any 
> special treatment (just tables and tree-tables)
> - deleting bean-reports and all of beancount/reports, or replacing most of 
> it by SQL queries
> - in the process deleting the Holdings code
> Basically, I think that with a slightly improved query engine I could 
> delete a ton of code without removing functionality at all.)
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beancount+unsubscr...@googlegroups.com.
To post to this group, send email to beancount@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beancount/fc515ea4-eb5b-4d25-84a9-d385022d3370%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Reports

[Daniel Clemente]

> The actual Javascript code of Fava only has 3 dependencies (plus one
polyfill to support MS Edge): d3 for charts, codemirror for the editors,
and Mousetrap for key bindings. I'm trying to keep this list minimal and I
believe all the dependencies we have are very much worth it as they allow
us to provide useful and powerful features that wouldn't be possible
otherwise.
> That high number is mostly a result of the build tools (rollup, used by
most JS libraries) and the lint tools for JS and CSS (eslint and stylelint
respectively).

Doing small code changes and building a new version is an important part of
how I use the code (at least I did some small changes in beancount), so
I'll still consider how simple are the build tools. Python scripts are
simple to modify, but the npm ecosystem seems much wilder. I can use Docker
as a jail if I don't trust the code, but I'd prefer code that I can trust
and understand.
Maybe it's possible to run fava without actually building any JS code? (No
linting, no minification, no JS packaging, …)

> Are there other aspects of Fava that you find too complex?

- all tables, which seem to dump accounting information without simplifying
it, e.g. mixing realized and unrealized accounts, writing too many
currencies, …
- many tables, because they require extensive accounting knowledge or
knowledge about beancount's internals (e.g. „holdings by cost currency“).
The UI is supposed to help me but it shows me more and more internals
- huge tables that I can't easily scroll
- queries that only show the query name, not the query string
- aggregates in balance tables; they're mixed with the original numbers
- treemaps mix many account levels without differentiating between level 1,
level 2, level 3, …
- information not correctly ordered (e.g. list of currencies ordered
alphabetically instead of relevance to the user)
- hidden „statistics“ (only find if you scroll down you find that there's
more things); very big tables in general
- and many more

> Many of the Fava's core features (like charts, the editor, journal
filtering, and toggleable account trees) can't be implemented without
Javascript, so it can't really work without JS. Is there a reason apart
from the complexity argument above for which you'd want to use it without
JS?

Well, I do graphs of my beancount data without JavaScript… I use Python.
With matplotlib I can also do interactive graphs (if I ever need it),
though I prefer to just generate many .png and then browse through them.
I'd like to see the simple beancount server (bean-web) generating .png
graphs and embedding them in the page.

I want the tools to be browsable without JS so that they integrate well in
the browser. JS wants to take the control about how to scroll, how to click
things, how to zoom, how to change to another page, how to load content,
whereas I'm fine with my browser doing all that, and I actually prefer it.
For instance, I like my way of moving through links with the keyboard, but
some clickable things in fava are not , but something different like
.
And more. JS well used (to bring more exploratory interactivity to graphs
and tables) could still be useful.


On Sun, Apr 8, 2018 at 1:42 PM, Jakob Schnitzer 
wrote:

> On Sun, Apr 01, 2018 at 10:03:43PM +0300, Daniel Clemente wrote:
>
>> I use bean-report for a few commands, mainly to get the price database,
>> and
>> all balances.
>> For most operations I use bean-query or the web interface, which is fast
>> and reliable.
>>
>> I don't use Fava and I feel it adds too much complexity. It depends on a
>> lot of external code that I don't have time to review (I just tried to
>> count it: npm wants to install 588 packages of JavaScript code!). Running
>>
>
> The actual Javascript code of Fava only has 3 dependencies (plus one
> polyfill to support MS Edge): d3 for charts, codemirror for the editors,
> and Mousetrap for key bindings. I'm trying to keep this list minimal and I
> believe all the dependencies we have are very much worth it as they allow
> us to provide useful and powerful features that wouldn't be possible
> otherwise.
>
> Are there other aspects of Fava that you find too complex?
>
> That high number is mostly a result of the build tools (rollup, used by
> most JS libraries) and the lint tools for JS and CSS (eslint and stylelint
> respectively).
>
> it inside a sandbox (Docker) is possible but it's harder to set up and this
>> infrastructure can have other problems.
>>
>
> A simple `pip install fava` will do, there's no need to install anything
> node-related yourself.
>
> Fava doesn't have the simplicity that I find in beancount. It also didn't
>> work without JS when I tried it some years ago (maybe it has improved).
>>
>
> Many of the Fava's core features (like charts, the editor, journal
> filtering, and toggleable account trees) can't be implemented without
> Javascript, so it can't really work without JS. Is there a reason apart
> from the complexity argument above for which you'd want

Re: Reports

[Jakob Schnitzer]

On Sun, Apr 01, 2018 at 01:53:19AM -0400, Martin Blais wrote:

How many people here use bean-report as their main way to generate data
from Beancount?
How many use bean-web?
Does anybody still care about bean-web now that Fava exists?

Also... is it possible to bean-bake Fava (or some equivalent creation of a
static version for sharing)?


It isn't, no (and it can't really be due to the amount of interactive 
switches, which would lead to an exponential number of pages).


Fava's templates could be used to implement some reduced static version 
like bean-bake though, removing the dependency on bean-reports.




Any input appreciated,


(Reason I'm asking is: I'm thinking about
- rewriting the query engine to something more powerful and general, and
promoting it from experimental and somewhat flaky to the main way of
getting data out
- rewriting bean-web to be a dumber, more generic web interface that
basically renders SQL queries (using the new query engine) without any
special treatment (just tables and tree-tables)
- deleting bean-reports and all of beancount/reports, or replacing most of
it by SQL queries
- in the process deleting the Holdings code
Basically, I think that with a slightly improved query engine I could
delete a ton of code without removing functionality at all.)

--
You received this message because you are subscribed to the Google Groups 
"Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beancount+unsubscr...@googlegroups.com.
To post to this group, send email to beancount@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beancount/CAK21%2BhPZh%2BRSFNoSDZd3PF%3Dh0ki2Utqv%3Dx%2BC%3D6dQpSiwX7S_ew%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups 
"Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beancount+unsubscr...@googlegroups.com.
To post to this group, send email to beancount@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beancount/20180408104740.GB9772%40js-arch.
For more options, visit https://groups.google.com/d/optout.

Re: Reports

[Jakob Schnitzer]

On Sun, Apr 01, 2018 at 10:03:43PM +0300, Daniel Clemente wrote:

I use bean-report for a few commands, mainly to get the price database, and
all balances.
For most operations I use bean-query or the web interface, which is fast
and reliable.

I don't use Fava and I feel it adds too much complexity. It depends on a
lot of external code that I don't have time to review (I just tried to
count it: npm wants to install 588 packages of JavaScript code!). Running


The actual Javascript code of Fava only has 3 dependencies (plus one 
polyfill to support MS Edge): d3 for charts, codemirror for the editors, 
and Mousetrap for key bindings. I'm trying to keep this list minimal and 
I believe all the dependencies we have are very much worth it as they 
allow us to provide useful and powerful features that wouldn't be 
possible otherwise.


Are there other aspects of Fava that you find too complex?

That high number is mostly a result of the build tools (rollup, used by 
most JS libraries) and the lint tools for JS and CSS (eslint and 
stylelint respectively).



it inside a sandbox (Docker) is possible but it's harder to set up and this
infrastructure can have other problems.


A simple `pip install fava` will do, there's no need to install anything 
node-related yourself.



Fava doesn't have the simplicity that I find in beancount. It also didn't
work without JS when I tried it some years ago (maybe it has improved).


Many of the Fava's core features (like charts, the editor, journal 
filtering, and toggleable account trees) can't be implemented without 
Javascript, so it can't really work without JS. Is there a reason apart 
from the complexity argument above for which you'd want to use it 
without JS?



I'd be fine with uglier web pages if they provide the basic accounting
needs. Though they don't need to be ugly.

I also use the holdings code and aggregate_holdings_by, but I could do the
same in some other way or keep the old code.


On Sun, Apr 1, 2018 at 8:53 AM, Martin Blais  wrote:


How many people here use bean-report as their main way to generate data
from Beancount?
How many use bean-web?
Does anybody still care about bean-web now that Fava exists?

Also... is it possible to bean-bake Fava (or some equivalent creation of a
static version for sharing)?

Any input appreciated,


(Reason I'm asking is: I'm thinking about
- rewriting the query engine to something more powerful and general, and
promoting it from experimental and somewhat flaky to the main way of
getting data out
- rewriting bean-web to be a dumber, more generic web interface that
basically renders SQL queries (using the new query engine) without any
special treatment (just tables and tree-tables)
- deleting bean-reports and all of beancount/reports, or replacing most of
it by SQL queries
- in the process deleting the Holdings code
Basically, I think that with a slightly improved query engine I could
delete a ton of code without removing functionality at all.)

--
You received this message because you are subscribed to the Google Groups
"Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to beancount+unsubscr...@googlegroups.com.
To post to this group, send email to beancount@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/
msgid/beancount/CAK21%2BhPZh%2BRSFNoSDZd3PF%3Dh0ki2Utqv%
3Dx%2BC%3D6dQpSiwX7S_ew%40mail.gmail.com

.
For more options, visit https://groups.google.com/d/optout.



--
You received this message because you are subscribed to the Google Groups 
"Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beancount+unsubscr...@googlegroups.com.
To post to this group, send email to beancount@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beancount/CAJKAhPD9qna%2BHq73uXsuw%3DNMqE4%3DdroVpm9cvGd1Fqch0eBhMg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups 
"Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beancount+unsubscr...@googlegroups.com.
To post to this group, send email to beancount@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beancount/20180408104254.GA9772%40js-arch.
For more options, visit https://groups.google.com/d/optout.

Re: Reports

[Dominik Aumayr]

> In fact, I would expect that Fava would eventually integrate some of that 
> functionality, e.g., adding a page with a query at the top and doing a 
> generic rendering of the results.

Fava does this already, see the "Query" page in the sidebar. 


> Am 04.04.2018 um 02:46 schrieb Martin Blais :
> 
> On Tue, Apr 3, 2018 at 12:10 AM, Mattijs Hoitink  
> wrote:
> I used bean-report for some simple stuff but never used bean-web, I went 
> straight for fava. Fava has become even easier to use now that it has an 
> electron shell.
> 
> I am interested in a more powerful query language because I'm exploring 
> custom reports for my personal ledger. Something separate that works with 
> beancount and can be built upon sounds like a sweet deal :)
> 
> To iterate on that: I would definitely make that new thing as minimal (and 
> minimal-looking so) as possible so it doesn't "compete" attention with a 
> full-fledged web front-end like Fava. In fact, I would expect that Fava would 
> eventually integrate some of that functionality, e.g., adding a page with a 
> query at the top and doing a generic rendering of the results.
> 
> 
> 
>  
> On Sunday, April 1, 2018 at 8:07:05 PM UTC-7, Martin Blais wrote:
> On Sun, Apr 1, 2018 at 2:10 PM, Stefano Zacchiroli  wrote:
> On Sun, Apr 01, 2018 at 01:53:19AM -0400, Martin Blais wrote:
> > - rewriting bean-web to be a dumber, more generic web interface that
> > basically renders SQL queries (using the new query engine) without any
> > special treatment (just tables and tree-tables)
> 
> Given Fava does that too, and also provides useful reporting out of the
> box, would it be worth to have another implementation of the same "web
> based bean-query console" thing? (Maybe yes, if, say, you consider that
> Fava has too many additional dependencies. Asking just to understand
> which design constraints you're considering.)
> 
> It would be different; all the pages would have a single query at the top 
> (which would be visible and which the user could tweak), and rendering would 
> have simple generic rules (e.g. match account name patterns) to create links 
> to e.g. journal pages which, again, would just be queries, but otherwise just 
> render generically (e.g. no special rendering for journals to show postings 
> and such, for instance, which I've always found ugly anyway), even the first 
> version would just render the text in a  tag, really bare bones. The 
> idea is definitely to avoid replicating Fava or bean-web, but instead provide 
> something that's doing 60~80% of that functionality with an incredibly simple 
> implementation (like, one file, calling out to bean-query library code). 
> Basically, a web-based interface to a more powerful and generic bean-query.
> 
> Now the twist in the plot: bean-query itself would expand in scope to go 
> beyond Beancount. I'm thinking of generalizing this to make it a row-based 
> (slow) query engine on in-memory tables, something that would be used akin to 
> the "re" library, and that would fit in the space that Pandas is currently 
> in, as well as supporting various input data formats (e.g. you could use it 
> to make queries on a CSV table, for example, or on a filesystem directory, or 
> e.g. on the EXIF files of a list of JPEG files, whatever data sources are 
> implemented, I can imagine many). It would be a generic library that you 
> could instantiate and customize to provide SQL-like functionality to any 
> (Python) program. It would be extensible (allowing you to add new datatypes 
> and control the set of available functions), and Beancount would basically 
> become its first use case of customization (providing Amount, Position and 
> Inventory data types and associated aggregation functions, and a few data 
> sources/tables, "transactions" being the main one, but also one table type 
> for each other directive, e.g. "commodities", etc.). It would support joins 
> and structured fields (e.g. so you could join with per-commodity or 
> per-account metadata, to implement e.g. your own section categorization), and 
> it would provide a command-line tool (to fill in those cases where awk leaves 
> you wanting), but also find a lot of usage from within Python as a library 
> (e.g., like one uses Pandas, on in-memory data tables). It would 
> automatically infer schemas by e.g. looking at the contents of a CSV file, 
> you can usually automatically infer the data types and column names from the 
> header, so it would become an ultimate CSV manipulation tool (I've surveyed 
> the other ones out there, what I've seen falls short of what I'd like to 
> have). Personally I think this could make general data manipulation easier 
> than many of the libraries out there (e.g. Pandas), at least for those cases 
> where performance isn't a concern (simplistic row-based implementation, at 
> least at first) and doing aggregations and pivots and such isn't as easy with 
> just the unix tools than what you can do in a single SQL expres

Re: Reports

[Martin Blais]

On Tue, Apr 3, 2018 at 12:10 AM, Mattijs Hoitink 
wrote:

> I used bean-report for some simple stuff but never used bean-web, I went
> straight for fava. Fava has become even easier to use now that it has an
> electron shell.
>
> I am interested in a more powerful query language because I'm exploring
> custom reports for my personal ledger. Something separate that works with
> beancount and can be built upon sounds like a sweet deal :)
>

To iterate on that: I would definitely make that new thing as minimal (and
minimal-looking so) as possible so it doesn't "compete" attention with a
full-fledged web front-end like Fava. In fact, I would expect that Fava
would eventually integrate some of that functionality, e.g., adding a page
with a query at the top and doing a generic rendering of the results.





> On Sunday, April 1, 2018 at 8:07:05 PM UTC-7, Martin Blais wrote:
>>
>> On Sun, Apr 1, 2018 at 2:10 PM, Stefano Zacchiroli 
>> wrote:
>>
>>> On Sun, Apr 01, 2018 at 01:53:19AM -0400, Martin Blais wrote:
>>> > - rewriting bean-web to be a dumber, more generic web interface that
>>> > basically renders SQL queries (using the new query engine) without any
>>> > special treatment (just tables and tree-tables)
>>>
>>> Given Fava does that too, and also provides useful reporting out of the
>>> box, would it be worth to have another implementation of the same "web
>>> based bean-query console" thing? (Maybe yes, if, say, you consider that
>>> Fava has too many additional dependencies. Asking just to understand
>>> which design constraints you're considering.)
>>>
>>
>> It would be different; all the pages would have a single query at the top
>> (which would be visible and which the user could tweak), and rendering
>> would have simple generic rules (e.g. match account name patterns) to
>> create links to e.g. journal pages which, again, would just be queries, but
>> otherwise just render generically (e.g. no special rendering for journals
>> to show postings and such, for instance, which I've always found ugly
>> anyway), even the first version would just render the text in a  tag,
>> really bare bones. The idea is definitely to avoid replicating Fava or
>> bean-web, but instead provide something that's doing 60~80% of that
>> functionality with an incredibly simple implementation (like, one file,
>> calling out to bean-query library code). Basically, a web-based interface
>> to a more powerful and generic bean-query.
>>
>> Now the twist in the plot: bean-query itself would expand in scope to go
>> beyond Beancount. I'm thinking of generalizing this to make it a row-based
>> (slow) query engine on in-memory tables, something that would be used akin
>> to the "re" library, and that would fit in the space that Pandas is
>> currently in, as well as supporting various input data formats (e.g. you
>> could use it to make queries on a CSV table, for example, or on a
>> filesystem directory, or e.g. on the EXIF files of a list of JPEG files,
>> whatever data sources are implemented, I can imagine many). It would be a
>> generic library that you could instantiate and customize to provide
>> SQL-like functionality to any (Python) program. It would be extensible
>> (allowing you to add new datatypes and control the set of available
>> functions), and Beancount would basically become its first use case of
>> customization (providing Amount, Position and Inventory data types and
>> associated aggregation functions, and a few data sources/tables,
>> "transactions" being the main one, but also one table type for each other
>> directive, e.g. "commodities", etc.). It would support joins and structured
>> fields (e.g. so you could join with per-commodity or per-account metadata,
>> to implement e.g. your own section categorization), and it would provide a
>> command-line tool (to fill in those cases where awk leaves you wanting),
>> but also find a lot of usage from within Python as a library (e.g., like
>> one uses Pandas, on in-memory data tables). It would automatically infer
>> schemas by e.g. looking at the contents of a CSV file, you can usually
>> automatically infer the data types and column names from the header, so it
>> would become an ultimate CSV manipulation tool (I've surveyed the other
>> ones out there, what I've seen falls short of what I'd like to have).
>> Personally I think this could make general data manipulation easier than
>> many of the libraries out there (e.g. Pandas), at least for those cases
>> where performance isn't a concern (simplistic row-based implementation, at
>> least at first) and doing aggregations and pivots and such isn't as easy
>> with just the unix tools than what you can do in a single SQL expression. I
>> spent some time in the past prototyping something like this using sqlite3 -
>> it looks like it's designed to be extensible - but it has proved too
>> difficult and not customizable enough to replace bean-query, we still need
>> something a more customizable than what this offers.

Re: Reports

[Daniel Clemente]

I use bean-report for a few commands, mainly to get the price database, and
all balances.
For most operations I use bean-query or the web interface, which is fast
and reliable.

I don't use Fava and I feel it adds too much complexity. It depends on a
lot of external code that I don't have time to review (I just tried to
count it: npm wants to install 588 packages of JavaScript code!). Running
it inside a sandbox (Docker) is possible but it's harder to set up and this
infrastructure can have other problems.
Fava doesn't have the simplicity that I find in beancount. It also didn't
work without JS when I tried it some years ago (maybe it has improved).

I'd be fine with uglier web pages if they provide the basic accounting
needs. Though they don't need to be ugly.

I also use the holdings code and aggregate_holdings_by, but I could do the
same in some other way or keep the old code.


On Sun, Apr 1, 2018 at 8:53 AM, Martin Blais  wrote:

> How many people here use bean-report as their main way to generate data
> from Beancount?
> How many use bean-web?
> Does anybody still care about bean-web now that Fava exists?
>
> Also... is it possible to bean-bake Fava (or some equivalent creation of a
> static version for sharing)?
>
> Any input appreciated,
>
>
> (Reason I'm asking is: I'm thinking about
> - rewriting the query engine to something more powerful and general, and
> promoting it from experimental and somewhat flaky to the main way of
> getting data out
> - rewriting bean-web to be a dumber, more generic web interface that
> basically renders SQL queries (using the new query engine) without any
> special treatment (just tables and tree-tables)
> - deleting bean-reports and all of beancount/reports, or replacing most of
> it by SQL queries
> - in the process deleting the Holdings code
> Basically, I think that with a slightly improved query engine I could
> delete a ton of code without removing functionality at all.)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Beancount" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beancount+unsubscr...@googlegroups.com.
> To post to this group, send email to beancount@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beancount/CAK21%2BhPZh%2BRSFNoSDZd3PF%3Dh0ki2Utqv%
> 3Dx%2BC%3D6dQpSiwX7S_ew%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beancount+unsubscr...@googlegroups.com.
To post to this group, send email to beancount@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beancount/CAJKAhPD9qna%2BHq73uXsuw%3DNMqE4%3DdroVpm9cvGd1Fqch0eBhMg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Reports

[Mattijs Hoitink]

hmm, that is unfortunate but makes sense if it's broken. I hadn't noticed 
any issues (yet)

On Monday, April 2, 2018 at 10:26:20 PM UTC-7, Dominik Aumayr wrote:
>
> > Fava has become even easier to use now that it has an electron shell. 
>
> Please note that the Electron shell will go away in the next version: 
> https://github.com/beancount/fava/pull/692 
>
>
> > Am 03.04.2018 um 06:10 schrieb Mattijs Hoitink  >: 
> > 
> > I used bean-report for some simple stuff but never used bean-web, I went 
> straight for fava. Fava has become even easier to use now that it has an 
> electron shell. 
> > 
> > I am interested in a more powerful query language because I'm exploring 
> custom reports for my personal ledger. Something separate that works with 
> beancount and can be built upon sounds like a sweet deal :) 
> > 
> > On Sunday, April 1, 2018 at 8:07:05 PM UTC-7, Martin Blais wrote: 
> > On Sun, Apr 1, 2018 at 2:10 PM, Stefano Zacchiroli  
> wrote: 
> > On Sun, Apr 01, 2018 at 01:53:19AM -0400, Martin Blais wrote: 
> > > - rewriting bean-web to be a dumber, more generic web interface that 
> > > basically renders SQL queries (using the new query engine) without any 
> > > special treatment (just tables and tree-tables) 
> > 
> > Given Fava does that too, and also provides useful reporting out of the 
> > box, would it be worth to have another implementation of the same "web 
> > based bean-query console" thing? (Maybe yes, if, say, you consider that 
> > Fava has too many additional dependencies. Asking just to understand 
> > which design constraints you're considering.) 
> > 
> > It would be different; all the pages would have a single query at the 
> top (which would be visible and which the user could tweak), and rendering 
> would have simple generic rules (e.g. match account name patterns) to 
> create links to e.g. journal pages which, again, would just be queries, but 
> otherwise just render generically (e.g. no special rendering for journals 
> to show postings and such, for instance, which I've always found ugly 
> anyway), even the first version would just render the text in a  tag, 
> really bare bones. The idea is definitely to avoid replicating Fava or 
> bean-web, but instead provide something that's doing 60~80% of that 
> functionality with an incredibly simple implementation (like, one file, 
> calling out to bean-query library code). Basically, a web-based interface 
> to a more powerful and generic bean-query. 
> > 
> > Now the twist in the plot: bean-query itself would expand in scope to go 
> beyond Beancount. I'm thinking of generalizing this to make it a row-based 
> (slow) query engine on in-memory tables, something that would be used akin 
> to the "re" library, and that would fit in the space that Pandas is 
> currently in, as well as supporting various input data formats (e.g. you 
> could use it to make queries on a CSV table, for example, or on a 
> filesystem directory, or e.g. on the EXIF files of a list of JPEG files, 
> whatever data sources are implemented, I can imagine many). It would be a 
> generic library that you could instantiate and customize to provide 
> SQL-like functionality to any (Python) program. It would be extensible 
> (allowing you to add new datatypes and control the set of available 
> functions), and Beancount would basically become its first use case of 
> customization (providing Amount, Position and Inventory data types and 
> associated aggregation functions, and a few data sources/tables, 
> "transactions" being the main one, but also one table type for each other 
> directive, e.g. "commodities", etc.). It would support joins and structured 
> fields (e.g. so you could join with per-commodity or per-account metadata, 
> to implement e.g. your own section categorization), and it would provide a 
> command-line tool (to fill in those cases where awk leaves you wanting), 
> but also find a lot of usage from within Python as a library (e.g., like 
> one uses Pandas, on in-memory data tables). It would automatically infer 
> schemas by e.g. looking at the contents of a CSV file, you can usually 
> automatically infer the data types and column names from the header, so it 
> would become an ultimate CSV manipulation tool (I've surveyed the other 
> ones out there, what I've seen falls short of what I'd like to have). 
> Personally I think this could make general data manipulation easier than 
> many of the libraries out there (e.g. Pandas), at least for those cases 
> where performance isn't a concern (simplistic row-based implementation, at 
> least at first) and doing aggregations and pivots and such isn't as easy 
> with just the unix tools than what you can do in a single SQL expression. I 
> spent some time in the past prototyping something like this using sqlite3 - 
> it looks like it's designed to be extensible - but it has proved too 
> difficult and not customizable enough to replace bean-query, we still need 
> something a more customizable

Re: Reports

[Dominik Aumayr]

> Fava has become even easier to use now that it has an electron shell.

Please note that the Electron shell will go away in the next version: 
https://github.com/beancount/fava/pull/692


> Am 03.04.2018 um 06:10 schrieb Mattijs Hoitink :
> 
> I used bean-report for some simple stuff but never used bean-web, I went 
> straight for fava. Fava has become even easier to use now that it has an 
> electron shell.
> 
> I am interested in a more powerful query language because I'm exploring 
> custom reports for my personal ledger. Something separate that works with 
> beancount and can be built upon sounds like a sweet deal :)
> 
> On Sunday, April 1, 2018 at 8:07:05 PM UTC-7, Martin Blais wrote:
> On Sun, Apr 1, 2018 at 2:10 PM, Stefano Zacchiroli  wrote:
> On Sun, Apr 01, 2018 at 01:53:19AM -0400, Martin Blais wrote:
> > - rewriting bean-web to be a dumber, more generic web interface that
> > basically renders SQL queries (using the new query engine) without any
> > special treatment (just tables and tree-tables)
> 
> Given Fava does that too, and also provides useful reporting out of the
> box, would it be worth to have another implementation of the same "web
> based bean-query console" thing? (Maybe yes, if, say, you consider that
> Fava has too many additional dependencies. Asking just to understand
> which design constraints you're considering.)
> 
> It would be different; all the pages would have a single query at the top 
> (which would be visible and which the user could tweak), and rendering would 
> have simple generic rules (e.g. match account name patterns) to create links 
> to e.g. journal pages which, again, would just be queries, but otherwise just 
> render generically (e.g. no special rendering for journals to show postings 
> and such, for instance, which I've always found ugly anyway), even the first 
> version would just render the text in a  tag, really bare bones. The 
> idea is definitely to avoid replicating Fava or bean-web, but instead provide 
> something that's doing 60~80% of that functionality with an incredibly simple 
> implementation (like, one file, calling out to bean-query library code). 
> Basically, a web-based interface to a more powerful and generic bean-query.
> 
> Now the twist in the plot: bean-query itself would expand in scope to go 
> beyond Beancount. I'm thinking of generalizing this to make it a row-based 
> (slow) query engine on in-memory tables, something that would be used akin to 
> the "re" library, and that would fit in the space that Pandas is currently 
> in, as well as supporting various input data formats (e.g. you could use it 
> to make queries on a CSV table, for example, or on a filesystem directory, or 
> e.g. on the EXIF files of a list of JPEG files, whatever data sources are 
> implemented, I can imagine many). It would be a generic library that you 
> could instantiate and customize to provide SQL-like functionality to any 
> (Python) program. It would be extensible (allowing you to add new datatypes 
> and control the set of available functions), and Beancount would basically 
> become its first use case of customization (providing Amount, Position and 
> Inventory data types and associated aggregation functions, and a few data 
> sources/tables, "transactions" being the main one, but also one table type 
> for each other directive, e.g. "commodities", etc.). It would support joins 
> and structured fields (e.g. so you could join with per-commodity or 
> per-account metadata, to implement e.g. your own section categorization), and 
> it would provide a command-line tool (to fill in those cases where awk leaves 
> you wanting), but also find a lot of usage from within Python as a library 
> (e.g., like one uses Pandas, on in-memory data tables). It would 
> automatically infer schemas by e.g. looking at the contents of a CSV file, 
> you can usually automatically infer the data types and column names from the 
> header, so it would become an ultimate CSV manipulation tool (I've surveyed 
> the other ones out there, what I've seen falls short of what I'd like to 
> have). Personally I think this could make general data manipulation easier 
> than many of the libraries out there (e.g. Pandas), at least for those cases 
> where performance isn't a concern (simplistic row-based implementation, at 
> least at first) and doing aggregations and pivots and such isn't as easy with 
> just the unix tools than what you can do in a single SQL expression. I spent 
> some time in the past prototyping something like this using sqlite3 - it 
> looks like it's designed to be extensible - but it has proved too difficult 
> and not customizable enough to replace bean-query, we still need something a 
> more customizable than what this offers.
> 
> bean-web currently uses the convoluted bean-report code, which I would love 
> to delete (it annoys me as it's not super generalized, e.g. not all of the 
> reports support the same sets of outputs, and it's very ugl

Re: Reports

[Mattijs Hoitink]

I used bean-report for some simple stuff but never used bean-web, I went 
straight for fava. Fava has become even easier to use now that it has an 
electron shell.

I am interested in a more powerful query language because I'm exploring 
custom reports for my personal ledger. Something separate that works with 
beancount and can be built upon sounds like a sweet deal :)

On Sunday, April 1, 2018 at 8:07:05 PM UTC-7, Martin Blais wrote:
>
> On Sun, Apr 1, 2018 at 2:10 PM, Stefano Zacchiroli  > wrote:
>
>> On Sun, Apr 01, 2018 at 01:53:19AM -0400, Martin Blais wrote:
>> > - rewriting bean-web to be a dumber, more generic web interface that
>> > basically renders SQL queries (using the new query engine) without any
>> > special treatment (just tables and tree-tables)
>>
>> Given Fava does that too, and also provides useful reporting out of the
>> box, would it be worth to have another implementation of the same "web
>> based bean-query console" thing? (Maybe yes, if, say, you consider that
>> Fava has too many additional dependencies. Asking just to understand
>> which design constraints you're considering.)
>>
>
> It would be different; all the pages would have a single query at the top 
> (which would be visible and which the user could tweak), and rendering 
> would have simple generic rules (e.g. match account name patterns) to 
> create links to e.g. journal pages which, again, would just be queries, but 
> otherwise just render generically (e.g. no special rendering for journals 
> to show postings and such, for instance, which I've always found ugly 
> anyway), even the first version would just render the text in a  tag, 
> really bare bones. The idea is definitely to avoid replicating Fava or 
> bean-web, but instead provide something that's doing 60~80% of that 
> functionality with an incredibly simple implementation (like, one file, 
> calling out to bean-query library code). Basically, a web-based interface 
> to a more powerful and generic bean-query.
>
> Now the twist in the plot: bean-query itself would expand in scope to go 
> beyond Beancount. I'm thinking of generalizing this to make it a row-based 
> (slow) query engine on in-memory tables, something that would be used akin 
> to the "re" library, and that would fit in the space that Pandas is 
> currently in, as well as supporting various input data formats (e.g. you 
> could use it to make queries on a CSV table, for example, or on a 
> filesystem directory, or e.g. on the EXIF files of a list of JPEG files, 
> whatever data sources are implemented, I can imagine many). It would be a 
> generic library that you could instantiate and customize to provide 
> SQL-like functionality to any (Python) program. It would be extensible 
> (allowing you to add new datatypes and control the set of available 
> functions), and Beancount would basically become its first use case of 
> customization (providing Amount, Position and Inventory data types and 
> associated aggregation functions, and a few data sources/tables, 
> "transactions" being the main one, but also one table type for each other 
> directive, e.g. "commodities", etc.). It would support joins and structured 
> fields (e.g. so you could join with per-commodity or per-account metadata, 
> to implement e.g. your own section categorization), and it would provide a 
> command-line tool (to fill in those cases where awk leaves you wanting), 
> but also find a lot of usage from within Python as a library (e.g., like 
> one uses Pandas, on in-memory data tables). It would automatically infer 
> schemas by e.g. looking at the contents of a CSV file, you can usually 
> automatically infer the data types and column names from the header, so it 
> would become an ultimate CSV manipulation tool (I've surveyed the other 
> ones out there, what I've seen falls short of what I'd like to have). 
> Personally I think this could make general data manipulation easier than 
> many of the libraries out there (e.g. Pandas), at least for those cases 
> where performance isn't a concern (simplistic row-based implementation, at 
> least at first) and doing aggregations and pivots and such isn't as easy 
> with just the unix tools than what you can do in a single SQL expression. I 
> spent some time in the past prototyping something like this using sqlite3 - 
> it looks like it's designed to be extensible - but it has proved too 
> difficult and not customizable enough to replace bean-query, we still need 
> something a more customizable than what this offers.
>
> bean-web currently uses the convoluted bean-report code, which I would 
> love to delete (it annoys me as it's not super generalized, e.g. not all of 
> the reports support the same sets of outputs, and it's very ugly OO-style 
> code). Doing this would force me to beef up the SQL functionality a bit to 
> support more, and make the "default" interface to Beancount just that.  I 
> think Fava is already covering the terrain in terms of providing a nice

Re: Reports

[Martin Blais]

On Sun, Apr 1, 2018 at 2:10 PM, Stefano Zacchiroli  wrote:

> On Sun, Apr 01, 2018 at 01:53:19AM -0400, Martin Blais wrote:
> > - rewriting bean-web to be a dumber, more generic web interface that
> > basically renders SQL queries (using the new query engine) without any
> > special treatment (just tables and tree-tables)
>
> Given Fava does that too, and also provides useful reporting out of the
> box, would it be worth to have another implementation of the same "web
> based bean-query console" thing? (Maybe yes, if, say, you consider that
> Fava has too many additional dependencies. Asking just to understand
> which design constraints you're considering.)
>

It would be different; all the pages would have a single query at the top
(which would be visible and which the user could tweak), and rendering
would have simple generic rules (e.g. match account name patterns) to
create links to e.g. journal pages which, again, would just be queries, but
otherwise just render generically (e.g. no special rendering for journals
to show postings and such, for instance, which I've always found ugly
anyway), even the first version would just render the text in a  tag,
really bare bones. The idea is definitely to avoid replicating Fava or
bean-web, but instead provide something that's doing 60~80% of that
functionality with an incredibly simple implementation (like, one file,
calling out to bean-query library code). Basically, a web-based interface
to a more powerful and generic bean-query.

Now the twist in the plot: bean-query itself would expand in scope to go
beyond Beancount. I'm thinking of generalizing this to make it a row-based
(slow) query engine on in-memory tables, something that would be used akin
to the "re" library, and that would fit in the space that Pandas is
currently in, as well as supporting various input data formats (e.g. you
could use it to make queries on a CSV table, for example, or on a
filesystem directory, or e.g. on the EXIF files of a list of JPEG files,
whatever data sources are implemented, I can imagine many). It would be a
generic library that you could instantiate and customize to provide
SQL-like functionality to any (Python) program. It would be extensible
(allowing you to add new datatypes and control the set of available
functions), and Beancount would basically become its first use case of
customization (providing Amount, Position and Inventory data types and
associated aggregation functions, and a few data sources/tables,
"transactions" being the main one, but also one table type for each other
directive, e.g. "commodities", etc.). It would support joins and structured
fields (e.g. so you could join with per-commodity or per-account metadata,
to implement e.g. your own section categorization), and it would provide a
command-line tool (to fill in those cases where awk leaves you wanting),
but also find a lot of usage from within Python as a library (e.g., like
one uses Pandas, on in-memory data tables). It would automatically infer
schemas by e.g. looking at the contents of a CSV file, you can usually
automatically infer the data types and column names from the header, so it
would become an ultimate CSV manipulation tool (I've surveyed the other
ones out there, what I've seen falls short of what I'd like to have).
Personally I think this could make general data manipulation easier than
many of the libraries out there (e.g. Pandas), at least for those cases
where performance isn't a concern (simplistic row-based implementation, at
least at first) and doing aggregations and pivots and such isn't as easy
with just the unix tools than what you can do in a single SQL expression. I
spent some time in the past prototyping something like this using sqlite3 -
it looks like it's designed to be extensible - but it has proved too
difficult and not customizable enough to replace bean-query, we still need
something a more customizable than what this offers.

bean-web currently uses the convoluted bean-report code, which I would love
to delete (it annoys me as it's not super generalized, e.g. not all of the
reports support the same sets of outputs, and it's very ugly OO-style
code). Doing this would force me to beef up the SQL functionality a bit to
support more, and make the "default" interface to Beancount just that.  I
think Fava is already covering the terrain in terms of providing a nice web
interface for Beancount and to make that out of scope for it wouldn't make
me sad at all (I'd rather let Dominik/Jakob and the rest of that team
continue to take over that space, there's a lot of changes going on there,
it's very dynamic, I see all the discussions, there's lots going on every
day).

This would result in less code for me to maintain, which in the long run is
probably a good thing for this project.  I want to move toward a smaller
codebase and a more streamlined core set of functionalities. Focus on
maintaining the core, focus on solving new problems, e.g. transaction vs.
settlement date

Re: Reports

[Leho Kraav]

On Sunday, April 1, 2018 at 12:53:42 AM UTC-5, Martin Blais wrote:
>
>
> - rewriting bean-web to be a dumber, more generic web interface that 
> basically renders SQL queries (using the new query engine) without any 
> special treatment (just tables and tree-tables)
>

Perhaps instead of rolling our own, it'd make sense to have people go with 
something like https://github.com/metabase/metabase 
(https://superset.incubator.apache.org seems more difficult) and have a 
really good query collection and a process for developing / updating 
queries.

-- 
You received this message because you are subscribed to the Google Groups 
"Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beancount+unsubscr...@googlegroups.com.
To post to this group, send email to beancount@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beancount/7392c4d5-9e82-4dcd-a70b-b441c99a8f5e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Reports

[Stefano Zacchiroli]

On Sun, Apr 01, 2018 at 01:53:19AM -0400, Martin Blais wrote:
> - rewriting bean-web to be a dumber, more generic web interface that
> basically renders SQL queries (using the new query engine) without any
> special treatment (just tables and tree-tables)

Given Fava does that too, and also provides useful reporting out of the
box, would it be worth to have another implementation of the same "web
based bean-query console" thing? (Maybe yes, if, say, you consider that
Fava has too many additional dependencies. Asking just to understand
which design constraints you're considering.)

-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

-- 
You received this message because you are subscribed to the Google Groups 
"Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beancount+unsubscr...@googlegroups.com.
To post to this group, send email to beancount@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beancount/20180401181026.GA3999%40upsilon.cc.
For more options, visit https://groups.google.com/d/optout.