bzr-plugin-info [suggest plugins at runtime]

[Michael Gliwinski]

Hi Robert,

On Monday 01 Mar 2010 08:18:37 Robert Collins wrote:
...
> bzr-plugin-info now hooks get_missing_command, and has the ability to
> write a db from its 'plugin-info' command. If you install bzr-plugin
> info and try something like 'bzr git-import' or 'bzr up-thread' when you
> have neither bzr-git or bzr-loom installed, you should get something
> nice like:
> 
> $ bzr git-import
> Command 'git-import' is not available at the moment.
> The following plugins include this command:
>  * git (branch available ../../git/trunk)
> 
> 
> The ../../path is because I scanned locally. Many plugins are missing
> metadata, and a number couldn't be scanned. So I've improved plugin-info
> to scan successfully in more cases, and submitted patches so that
> scanning does not error to all the plugins I had locally.

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)?

> 
> 
> What does this mean to you, as a plugin author?
> See
> http://doc.bazaar.canonical.com/bzr.dev/developers/plugin-api.html#plugin-m
> etadata-before-installation
> 
> For the docs: you should advertise the commands you ship,the formats you
> provide or can read, so that bzr plugin-info can scan your plugin.
> 
> To test, just point it at your local disk:
> cd my-plugin-dir
> bzr plugin-info .
> 
> I think a sensible next step would be to expand the metadata spec to
> accommodate hooks as well as some advertising docs, home page etc. (Some
> of these are available from setup.py PKG_INFO, but you have to build
> that to get at it: perhaps we should teach plugin-info how to do that as
> well.

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?

> 
> I'd like to see this (with a better list of urls) shipped to users by
> default in Lucid; we don't need it to be much more comprehensive; we
> don't need to have this perfect first, after all.
> 
> We could ship it by default a few different ways:
>  - bundle as a plugin in core
>  - recommend: in the binary packaging (and suggest other platforms do
> the same)
>  - ???
> 
> I don't have a strong preference. I have a weak preference to keep it
> outside the core: its been good for the core to prepare for this plugin,
> and I like to keep that clarity.
> 
> -Rob
> 


-- 
Michael Gliwinski
Henderson Group Information Services
9-11 Hightown Avenue, Newtownabby, BT36 4RT
Phone: 028 9034 3319

**********************************************************************************************
The information in this email is confidential and may be legally privileged.  It is intended solely for the addressee and access to the email by anyone else is unauthorised.
If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.
When addressed to our clients, any opinions or advice contained in this e-mail are subject to the terms and conditions expressed  in the governing client engagement leter or contract.
If you have received this email in error please notify support at henderson-group.com

John Henderson (Holdings) Ltd
Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern Ireland, BT36 4RT.
Registered in Northern Ireland
Registration Number NI010588
Vat No.: 814 6399 12
*********************************************************************************