On Sat, Dec 03, 2016 at 09:21:35AM -1000, Martin Blais wrote: > On Sat, Dec 3, 2016 at 1:48 AM, Stefano Zacchiroli <[email protected]> wrote: > > > > It would be useful at some point if you could document best > > practices or other expectations on how 3rd party plugins should be > > "bundled up". That would make it easy and consistent to use them for > > Beancount users. > > I keep it simple: if it's in your PYTHONPATH, and it has a __plugins__ > attribute, it's all good. There's no convention beyond that.
Sorry, I wasn't clear about what I meant with "bundle" here. I'm good on the Python API between Beancount and plugins; it's great, clear, and couldn't be simpler. But 3rd party plugins distributed as repos or tarballs can implement that API in many different ways. You can have a top-level Python module that you just git clone, or a deep module namespace that is grafted (beancount.plugins.AUTHOR_NAME.pluginN), or not (AUTHOR_NAME.beancount.pluginN), into the beancount one. >From the point of view of plugin users, dealing with these difference is gonna become tiresome at some point. So having some "Beancount 3rd party plugin *distribution* guidelines", with emphasis on distribution, would be nice. > If you want examples of testing plugins, see here: > https://bitbucket.org/blais/beancount/src/tip/src/python/beancount/plugins/ Here too, I did see that, which is helpeful if your plugin is eventually going to be integrated into the Beancount main codebase. But if your plugin is going to remain 3rd party, you need quite a bit of scaffolding before being able to test your plugin. Having a set of guidelines about how to do that for *external* plugins would be nice. Same thing for linting. You've some pylint settings sprinkled around the Beancount codebase, either in pylintrc or in individual files; for external plugins is not clear which rules should apply when using pylint. Maybe, joining this discussion with Dominik's proposal of CI plugin testing, what we need is a repo with 3rd party plugin *template*, that plugin author should start from. It can contain the desired module structure, testing scaffolding, and Travis integration. Hope this clarifies, Cheers. -- Stefano Zacchiroli . [email protected] . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader . OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » -- 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 post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/20161204102910.wiicnec56yud4xzi%40upsilon.cc. For more options, visit https://groups.google.com/d/optout.
