how do I debug plugins?

[martin.andr...@gmail.com]

So I'm attempting to write a plugin, but i'm at a loss as to how I debug it - even as far as just knowing the plugin is loaded. I've peeked around at the source code of other plugins, and the docs, but apparently my eyes are getting in the way of my vision. Any pointers?

[Justus Pendleton]

On Thursday, January 12, 2017 at 5:27:55 PM UTC+7, martin.andr...@gmail.com wrote:

So I'm attempting to write a plugin, but i'm at a loss as to how I debug it - even as far as just knowing the plugin is loaded.

I find a good way to get into any python program is to just slap a python debugger break point where I'm interested and then run the script.

import pdb; pdb.set_trace()

Then you can run bean-report or bean-check or anything else. You can look at the stack and generally figure out how things go to where they are.

The docs on writing plugins https://docs.google.com/document/d/1QftxNvQPdH-MikMBHupftU6F4IsNZP5FlFh1LCbVgk8/edit#heading=h.yshh8f17jbdb have a simple example (look for accounting.wash_sales) that can help you get started, too.

Does that help, or did you mean something else? 

[Martin Blais]

Hi Martin,

Sure. If you look under the beancount.plugins package, there are many many examples.

You write your plugin in a library file, and unit tests in the other.

For example, if your plugin is called "andersen", you would create these files next to each other:

- andersen.py

- ansersen_test.py

somewhere on your PYTHONPATH.

Then you would run nosetests on the test files to run all the unittests (from package python-nose, or just nose).

There are a lot of utility functions to automatically create input files from docstrings.

e.g. the beancount.loader.load_doc() decorator.

See the plugins directory, many of the tricks are used there.

Writing unit tests is the best way to debug things, because

- the inputs can be made minimal and specific to the particular code branch of feature you're testing

- they remain through the lifetime of the plugin, so you can just rerun them as the upstream Beancount code evolves

- you can easily run all of them at the same time

- they serve as documentation for your expectations of what the plugin does.

- they prevent regressions, as you evolve your plugin itself

I hope this helps,

On Thu, Jan 12, 2017 at 5:27 AM, <martin.andr...@gmail.com> wrote:

So I'm attempting to write a plugin, but i'm at a loss as to how I debug it - even as far as just knowing the plugin is loaded. I've peeked around at the source code of other plugins, and the docs, but apparently my eyes are getting in the way of my vision. Any pointers?

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to bean...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/89acc7a9-7142-4842-b39b-95165bb0d434%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Martin Andreas Andersen]

Thanks! That helps. 

On Fri, 13 Jan 2017 at 05.06, Martin Blais <bl...@furius.ca> wrote:

Hi Martin,

Sure. If you look under the beancount.plugins package, there are many many examples.

You write your plugin in a library file, and unit tests in the other.

For example, if your plugin is called "andersen", you would create these files next to each other:

- andersen.py

- ansersen_test.py

somewhere on your PYTHONPATH.

Then you would run nosetests on the test files to run all the unittests (from package python-nose, or just nose).

There are a lot of utility functions to automatically create input files from docstrings.

e.g. the beancount.loader.load_doc() decorator.

See the plugins directory, many of the tricks are used there.

Writing unit tests is the best way to debug things, because

- the inputs can be made minimal and specific to the particular code branch of feature you're testing

- they remain through the lifetime of the plugin, so you can just rerun them as the upstream Beancount code evolves

- you can easily run all of them at the same time

- they serve as documentation for your expectations of what the plugin does.

- they prevent regressions, as you evolve your plugin itself

I hope this helps,

On Thu, Jan 12, 2017 at 5:27 AM, <martin.andr...@gmail.com> wrote:

So I'm attempting to write a plugin, but i'm at a loss as to how I debug it - even as far as just knowing the plugin is loaded. I've peeked around at the source code of other plugins, and the docs, but apparently my eyes are getting in the way of my vision. Any pointers?

--


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.

To post to this group, send email to bean...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/89acc7a9-7142-4842-b39b-95165bb0d434%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--


You received this message because you are subscribed to a topic in the Google Groups "Beancount" group.


To unsubscribe from this topic, visit https://groups.google.com/d/topic/beancount/NCsq_G4POYk/unsubscribe.


To unsubscribe from this group and all its topics, send an email to beancount+...@googlegroups.com.

To post to this group, send email to bean...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhPgD6wVH5vPhdMyPM%2BNzgiT8DeFq50Xz8e%3Dup%2BbgcG%3Dzg%40mail.gmail.com.