On Tue, Apr 3, 2018 at 12:10 AM, Mattijs Hoitink <[email protected]> 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 <[email protected]> >> 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 <pre> 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 dates, automating the trading accounts idea for currencies, >> finally getting to properly calculating returns, stuff like that. My vision >> for a simplified future currently looks like this: >> >> - beancount.query -> transitions gradually to a new project, but which is >> cutomizable enough to support Beancount's data types, aggregation functions >> and data "tables" synthesized from its contents. >> - beancount -> remains core data structures & schema, grammar/parser, >> booking algorithm (the special sauce), prices, some scripts, as well as >> custom data types and table "data sources" for the query library >> - beancount.reports, beancount.web -> deprecated / deleted in the favor >> of Fava, or if you're a minimalist you'd use the simplistic new web-based >> interface to the query tool >> >> So in short the impetus is this: >> I would like to get rid of custom report code and the Holdings code, >> which is what bean-web is implemented with, therefore I'd like to get >> rid of bean-web as well, >> which is fine because Fava provides something better, >> but bean-bake relies on bean-web, and so I'm still not sure if >> zipping up Fava to a static web site is possible. >> >> (So far this is just an idea, nothing has been removed/done yet.) >> >> -- > 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 [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/beancount/8b2bcda8-f213-44aa-b999-4b41468a5412%40googlegroups.com > <https://groups.google.com/d/msgid/beancount/8b2bcda8-f213-44aa-b999-4b41468a5412%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhMUsa62W99p1-bgqaTt3caR4ahDaQzioPASz-vd3iV60w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
