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 <mattijs...@gmail.com > <javascript:>>: > > > > 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 <za...@upsilon.cc> > 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 beancount+...@googlegroups.com <javascript:>. > > To post to this group, send email to bean...@googlegroups.com > <javascript:>. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/beancount/8b2bcda8-f213-44aa-b999-4b41468a5412%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/6478085d-3594-4d09-9b18-7e02b7eff172%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
