I'll confess I haven't looked at the plugin architecture in detail (beyond
the docs, basically), but it seems to me that if a plugin is enabled by the
beancount directive, there are a couple of ways it could hook in in more
places:
- a plugin class or module couple implement "well known" function/method
names that are called in sequence at specific points in the processing flow
(as is done for importers with the extract/identify methods)
- a plugin module could register its own arbitrary callables to hooks with
something like "beancount.plugins.register_callback("post_booking",
myplugin.check_fifo)
I think the existing plugin architecture is fine for my purpose (raising an
error if the final processed directives are inconsistent with FIFO). But
adding a new named booking method could, in a generic framework of many
hooks as described above, just be a matter of providing hooks in the right
places for beancount to call out to plugins.
On Saturday, 5 June 2021 at 3:24:10 pm UTC+10 [email protected] wrote:
> That rules out using any of the CLIs that trampoline to Python unless they
> all get hooks too.
>
> What about keeping that single plugin directive but allow the plugin code
> to implement different interfaces depending on what plugin type it is?
>
> On Fri, Jun 4, 2021 at 10:16 PM Martin Blais <[email protected]> wrote:
>
>> Extra directives look ugly to me. Trying to keep the language lean.
>> I'd just have a Python-level feature and you'd have to write your own
>> main with load_file().
>> It's pretty exotic anyway.
>>
>> On Sat, Jun 5, 2021 at 12:53 AM Ben Blount <[email protected]> wrote:
>>
>>> Custom booking methods would be fantastic.
>>>
>>> Does anyone have thoughts on how such a registry would be configured?
>>> The only mechanism that comes to mind as workable would be to register
>>> it like plugins are currently. Given the plans to add pre-booking plugins
>>> in v3 that work on direct-from-parser inputs, I imagine those would take a
>>> similar approach.
>>>
>>> So maybe we'd have 2 additional plugin directives:
>>> pre_plugin <python_path>
>>> booking_plugin <python_path>
>>>
>>> which matches today's plugin <python_path>
>>>
>>> On Fri, Jun 4, 2021 at 9:28 PM [email protected] <
>>> [email protected]> wrote:
>>>
>>>> Thanks for the reply, Martin!
>>>>
>>>> In the absence of anyone piping up to say such a plugin already exists
>>>> that I've overlooked, I might implement this as a plugin first to share
>>>> with you all, and then consider contributing to a "custom booking method"
>>>> registry feature if there's interest in it. But it will be a little while
>>>> before I can contribute either in any case.
>>>>
>>>> On Saturday, 5 June 2021 at 2:20:16 pm UTC+10 [email protected] wrote:
>>>>
>>>>> Sure why not.
>>>>>
>>>>> But you could also write your own booking method that does just this
>>>>> instead?
>>>>> I would call it "CHECK_FIFO".
>>>>> (Problem is it's orthogonal to all the methods, e.g. CHECK_LIFO, etc..
>>>>> Whatever.)
>>>>>
>>>>> Right now I don't have a registration mechanism so you'd have to
>>>>> either
>>>>> - patch the code
>>>>> - monkey-patch the code without change the library (not sure if
>>>>> possible)
>>>>> - send me a patch to add a registry so you can do this cleanly
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jun 4, 2021 at 11:52 PM [email protected] <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Hi folks,
>>>>>>
>>>>>> I use a FIFO methodology for capital gains but with STRICT booking,
>>>>>> inputting the lots I sell explicitly (relying heavily on vim-beancount's
>>>>>> GetContext, but increasingly also automating this with importers that
>>>>>> accept the prior entries).
>>>>>>
>>>>>> I have two reasons: I'm affected by the "transfer lots with cost"
>>>>>> issue discussed at length in crypto contexts, but a crypto transfer with
>>>>>> a
>>>>>> fee means increasing the cost base slightly while preserving the date.
>>>>>> All
>>>>>> things considered, this is safer to do explicitly so I can see what's
>>>>>> going
>>>>>> on. I also find it personally preferable for everything to be explicitly
>>>>>> expressed in the text. It's aesthetically appealing and reassuring to me
>>>>>> that I haven't misunderstood beancount if it's done explicitly.
>>>>>>
>>>>>> Which brings me to my question: I have in mind a plugin that would
>>>>>> check the transactions after all the parsing and processing is complete,
>>>>>> and assert that the lots I've explicitly reduced are the ones that are
>>>>>> consistent with a FIFO approach.
>>>>>>
>>>>>> I think this is something useful and that I could reasonably write
>>>>>> (and open-source) when I have time, but I wanted to ask if anyone's
>>>>>> aware
>>>>>> of an existing plugin that does this?
>>>>>>
>>>>>> A further thought is that if I choose `option "booking_method"
>>>>>> "FIFO"`, then it would be extremely cool if beancount would not just
>>>>>> interpolate missing bookings according to FIFO but also consider it an
>>>>>> error if I have explicitly booked a reduction that doesn't conform to
>>>>>> FIFO.
>>>>>> I'll leave it up to Martin to decide whether this validation is in the
>>>>>> scope of `booking_method` or whether this belongs to a plugin.
>>>>>>
>>>>>> Thanks for reading!
>>>>>>
>>>>>> --
>>>>>> 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 on the web visit
>>>>>> https://groups.google.com/d/msgid/beancount/2a2682b6-83d9-4288-a3d5-c7c5b2659cafn%40googlegroups.com
>>>>>>
>>>>>> <https://groups.google.com/d/msgid/beancount/2a2682b6-83d9-4288-a3d5-c7c5b2659cafn%40googlegroups.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 on the web visit
>>>> https://groups.google.com/d/msgid/beancount/37a15b36-1b13-4166-9402-2a81f4c56249n%40googlegroups.com
>>>>
>>>> <https://groups.google.com/d/msgid/beancount/37a15b36-1b13-4166-9402-2a81f4c56249n%40googlegroups.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 on the web visit
>>> https://groups.google.com/d/msgid/beancount/CACGEkZtm9-OuYNxk8ccseyqPYrwT-nGPMdNyZiovLN%2Bp2kGRGA%40mail.gmail.com
>>>
>>> <https://groups.google.com/d/msgid/beancount/CACGEkZtm9-OuYNxk8ccseyqPYrwT-nGPMdNyZiovLN%2Bp2kGRGA%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 on the web visit
>> https://groups.google.com/d/msgid/beancount/CAK21%2BhPTCp_%3D%2BSCfVEqZdHDcTqhLNhdPn2pyMRPgu9Owda%2BxCQ%40mail.gmail.com
>>
>> <https://groups.google.com/d/msgid/beancount/CAK21%2BhPTCp_%3D%2BSCfVEqZdHDcTqhLNhdPn2pyMRPgu9Owda%2BxCQ%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 on the web visit
https://groups.google.com/d/msgid/beancount/54b8e336-00aa-47f9-acdd-44b2f8162500n%40googlegroups.com.
