Dart? Awesome! I extracted all the OG Beancount parser tests from their original Python into language-independent files here:
https://github.com/tesujimath/beancount-parser-lima/tree/main/test-cases Input files are standalone Beancount. Expected output as text protobuf. All credit to Martin for the original tests! I'm afraid my booking tests are embedded in Rust, sorry. (Also adapted from Martin's originals.) https://github.com/tesujimath/limabean/blob/main/rust%2Flimabean-booking%2Fsrc%2Ftests%2Fbooking.rs On Sat, 28 Feb 2026, 2:10 pm Vishesh Handa, <[email protected]> wrote: > > Martin has made a huge contribution to the plain text accounting > community, both with the very well designed original Beancount system which > we all love, and also the extensive documentation and test suite. Thank > you indeed! These were certainly enablers for my own limabean > <https://github.com/tesujimath/limabean>. > > > > 1. Preserving a common file format > > 2. Preserving common core behaviour > > I'd love some language independent tests which can be used in all > beancount inspired projects. So ideally some standard input bean files, and > some machine readable (maybe json) expected outputs. > > Essentially some easy way to check that account balances are correct as > are the inventories and precision and what not. Basically, some black box > testing of all these beancount implementations, so that it's trivial to > know if any project complies with the beancount spec, and maybe even a way > of knowing which plugins it supports. > > I have an 80% finished beancount parser in Dart, which I just wrote for > fun, and it would be so helpful to know how terrible it is. > > > On Thu, 26 Feb 2026 at 01:55, 'Simon Guest' via Beancount < > [email protected]> wrote: > >> The Beancount developer landscape seems to be thriving at the moment with >> several recent announcements about new implementations. This is certainly >> exciting, and it's great to see such creativity. >> >> Martin has made a huge contribution to the plain text accounting >> community, both with the very well designed original Beancount system which >> we all love, and also the extensive documentation and test suite. Thank >> you indeed! These were certainly enablers for my own limabean >> <https://github.com/tesujimath/limabean>. >> >> And so now times are changing, and Beancount is in some ways being >> liberated from its Python origins. We are seeing work in Rust, Zig, >> Clojure, and who knows what to come. Exciting times indeed! But how will >> we avoid fragmentation? >> >> It is clear that in future we will have multiple implementations of >> Beancount-like systems. That is not what I am concerned about. My >> concerns are: >> >> 1. Preserving a common file format >> >> 2. Preserving common core behaviour >> >> I expect and celebrate a varied approach to user interface (Beancount >> Query Language, Fava, or Fava-like GUI, Clojure, whatever else). This is a >> fruitful area for exploration. So too, the plugin ecosystem will surely >> diverge. I agree with Moritz, the author of TurboBean >> <https://github.com/themoritz/turbobean> (cool project!) that you >> wouldn't want to embed a Python interpreter just for plugins if you don't >> already need it. And with limabean I am exploring the idea of not needing >> plugins at all. >> >> It should be easy for users to try out different implementations, which >> requires (1) and (2) above, and perhaps more. >> >> The vNext document <https://beancount.github.io/docs/beancount_v3.html> >> has some interesting ideas, which explains TurboBean diverging with a new >> approach to inventory. Is this the future? I would like to know, as I >> would then have to follow along with limabean! >> >> What I would really like to see is some kind of RFC process, like which >> is used for evolution of the Rust language and ecosystem. I hope that >> Martin would like to be the BDFL for some kind of RFC-like process which >> unifies all these parallel developments, in terms of defining core >> behaviour, *especially where this differs from OG Beancount* (in fact, >> probably only where it differs). >> >> In summary, I think we should embrace and celebrate the current >> divergence of implementation work in the Beancount ecosystem, but take some >> steps to mitigate the otherwise inevitable fragmentation. >> >> All comments welcome! >> >> -- >> 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 view this discussion visit >> https://groups.google.com/d/msgid/beancount/CAFhGSbuUFDWnn2vi9bZEV3%2BtKaaPTCKDdVW4jdmmS02NUVX1CA%40mail.gmail.com >> <https://groups.google.com/d/msgid/beancount/CAFhGSbuUFDWnn2vi9bZEV3%2BtKaaPTCKDdVW4jdmmS02NUVX1CA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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 view this discussion visit > https://groups.google.com/d/msgid/beancount/CAKb-1of4jW46%3DjU6ApRGCD_xaHKmvFQxo29eUBHir1o5qLdkMQ%40mail.gmail.com > <https://groups.google.com/d/msgid/beancount/CAKb-1of4jW46%3DjU6ApRGCD_xaHKmvFQxo29eUBHir1o5qLdkMQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 view this discussion visit https://groups.google.com/d/msgid/beancount/CAFhGSbuKFczBKgGX04V1aiTeykhiezG8OETqpDrnksETQLb6pg%40mail.gmail.com.
