To chime in on the topic, I don't know if you're aware of that list of plugins but that might give you a larger idea of how they operate on the ledger: https://github.com/beancount/beanlabs/tree/master/beanlabs/plugins
One of the plugin I rely on is ira_contribs.py (actually my own spin of it, adapted for Canadian tax-deferred and tax-free accounts). It adds postings to some transactions to help keep track of allowed contributions to those accounts. So for instance, if I transfer 1000 CAD from my checking account to a tax-deferred account, the plugin adds extra-postings to the transaction to decreased my "Assets:Allowance:TaxDeferred" account by the same amount. I don't know if such a plugin would work with limabean or not. So maybe you've made transaction pairing first-class citizen in limabean-harvest, but current beancount plugins can get pretty creative and you're going definitely have breakage if you change when plugins run. My personal 2 cents: the community is small already, so I would be careful to not introduce new not-retrocompatible ways of doing things. Le lundi 2 mars 2026 à 17:00:03 UTC-5, Simon Guest a écrit : > A limabean issue <https://github.com/tesujimath/limabean/issues/46> has > raised a question about how plugins should work, and highlighted that my > approach in limabean differs from the historical behaviour > <https://beancount.github.io/docs/beancount_scripting_plugins.html#load-pipeline> > . > > It comes down to, what are plugins for, actually? > > The specific plugin which initiated the discussion was zerosum > <https://github.com/redstreet/beancount_reds_plugins/tree/main/beancount_reds_plugins/zerosum>. > > Currently it is not possible to run such a plugin in limabean because > limabean plugins run after the booking process has completed, and until > such a plugin has run the beanfile is invalid. > > My first instinct was, well, fix the beanfile! That particular plugin > seems to be a mitigation for an import process which doesn't pair > transactions between accounts, in contrast to limabean-harvest > <https://github.com/tesujimath/limabean-harvest> for example, which > handles transaction pairing across accounts on import > <https://github.com/tesujimath/limabean-harvest/blob/main/clj/doc/10-features.md#transaction-pairing> > . > > My proposed mitigation for what I am calling such breakage (sorry) in > beanfiles would be to run user-defined functions over the beanfile whose > final output would be a fixed-up beanfile which passes validation. > > I understand there is legacy behaviour here. But the vNext document has > some interesting plugin-related discussion > <https://beancount.github.io/docs/beancount_v3.html#intermediate-parsed-data-vs-final-list-of-directives>, > > which says: > > > > *Furthermore, there may be two types of plugins: a plugin that runs on the > uninterpolated, unbooked output of the parser, and a plugin that runs on > the resolved and booked stream. This would allow more creative use of > partial input that might be invalid under the limitations of interpolation > and booking.Updates:- We could convert the plugin system to one that runs > at booking/interpolation time.* > > I am interested to understand other scenarios which would illuminate > design choices here. > -- 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/029ccd06-be04-4079-80c2-dd510a919185n%40googlegroups.com.
