bzr-plugin-info [suggest plugins at runtime]

[Martin Pool]

On 5 March 2010 19:57, Michael Gliwinski
<Michael.Gliwinski at henderson-group.com> wrote:

> Would that have to do the scanning and building the db on each client (i.e.
> each user who installed the plugin), or would it have some central directory
> component (e.g. sth like pypi)?

I think we would ship the database, probably in the form of a Python
source file that declares a series of dicts.  The plugin (or a
separate plugin) could contain the code to regenerate this, given a
list of plugins.  Obviously it should be  careful to be fast.

> That's another thing.  There's already some amount of duplication there (e.g.
> having to specify version both in setup.py and __init__.py, same usually
> happens for author, dependencies, etc.).  It's nothing to do with bzr itself,
> just how distutils works.  Still, there are things that could be done about
> this, the easiest may be a simple convention to say, define this sort of
> metadata in a submodule with some well-known name (meta, plugin_meta,
> pkg_info, etc.), this could then be used both at runtime and from setup.py.
>
> What do you think?  Maybe there are better ways?

It is a bit messy.  Putting it into a separate file meta.py causes
problems loading it after the package is installed.  I think having
setup.py load it from a file inside the module is probably ok as long
as some care is taken.

You could argue plugin-info should read some of this from the plugin
itself rather than the metafile but at this point getting the whole
thing connected end to end is probably more important than futzing
with just where it's defined.

-- 
Martin <http://launchpad.net/~mbp/>