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> . FWIW, the issue that zerosum addresses isn’t about mitigating pairing deficiencies at import. Its purpose is to support asynchronous imports of the two sides of a transaction and to accurately represent transfers that are temporarily “in flight.” Financial institutions differ in how up-to-date their transaction feeds are, and in practice users often import some accounts frequently while updating others only periodically. As a result, asynchronous imports are often unavoidable. In the U.S., transfers also do not settle instantly, which can complicate synchronization with an institution’s transaction sequence and balance assertions. One alternative is to reconcile and rewrite the existing ledger once the second side of a transfer arrives, but that approach carries its own trade-offs rather than being a clearly superior solution. Anyway, I digress. Other plugins like <https://github.com/redstreet/beancount_reds_plugins> opengroup, and possibly rename_accounts and effective_date need to run early in the proccess. Not to mention homecooked plugins. On Tuesday, March 3, 2026 at 6:57:51 AM UTC-8 Damien R. wrote: 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).. [...] 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.* Emphasis mine, +1. -- 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/ba1553b5-0e2a-4c20-80be-d64d14c83c58n%40googlegroups.com.
