[RFC] Automatic Plugin Suggestion

[Robert Collins]

On Mon, 2008-02-18 at 20:00 -0200, Martin Albisetti wrote:
> On Feb 17, 2008 8:07 PM, Robert Collins <robertc at robertcollins.net> wrote:
> > The provider returned should be usable already and not need a factory
> > called on it. Just register an instance and not a type. (We try to avoid
> > registries conflating registration with logic unless they are clearly
> > the same thing).
> >
> > The method 'check_for_plugin' is confusingly named. Its looking for the
> > plugin that provides a name, so find_plugin(name), or
> > plugin_for_command(name) seem clearer to me.
> 
> Seems much cleaner. I'll work on this.
> 
> > I'm not sure that bzrlib.plugin is the right point to hook this; its
> > nothing to do with loading plugins, and everything to do with hooking
> > into command logic.
> 
> So this would go into commands.py?


There's some room for discussion. Martin Pool has convinced me that
having separated directory service and installation service makes
sense. 

This adds some complexity though: We can't refer to a plugin just by
name, because a different installer may handle the request than the
directory service. If you consider plugin FOO being updated from 1.2 to
1.3, and adding a new command at the same time; then we have to ensure
that FOO 1.3 is retrieved by the installer, not 1.2 - and binary
packages /will/ interact with this badly. We also need to ensure that
the search-path-for-packages is understood when selecting the installer,
because a homedir installed plugin will override a system wide installed
one, and so on.

We may wish to have a single directory service that understands many
different queries though. In which case the /directory/ service registry
can live in plugin.py.

Certainly all the command-centric stuff should be in commands.py.

> > I think a global option to bzr '--auto-install' would be cool, then you
> > can just repeat the command with --auto-install, and bzr will install
> > the plugin and then run your command.
> >
> > But we probably need new core commands anyhow:
> > cmd_install_plugin
> > cmd_uninstall_plugin
> >
> > Because multiple providers can provide the same plugin, install
> > plugin /may/ need something like:
> > bzr install-plugin --command bisect
> > (which will just install bisect from the first provider, using the same
> > loop that command errors use). I think this is nice because the error
> > can instruct people to run this exact command.
> > And in future control directory errors can report
> > "please run bzr install-plugin --format hg2" to get support for hg
> > installed easily.
> 
> I'll add this to the spec for the next stage.

So we need two concepts:
PluginDirectoryService
  plugin_for_command
  get_control_directory_patterns
  ... more over time ...

PluginPackager
  install(plugin_details)
  uninstall(plugin_module)

> > I don't think any of the code you put in bzrlib.plugins should be merged
> > to core - its just a lookup provider, and I expect that for most users
> > this provider won't be desirable as it is not OS packaging system
> > integrated.
> 
> The current code doesn't provide anything OS-specific, just the lookup
> functions.
> Is this asuming that each provider will have it's own DB?

Martin Pool and I disagree about whether bzr's core tree should have any
directory service and plugin packaging implementations. I think they
shouldn't, and that we should ship a tarball for users that is more than
the core tree. Our error message when there is no packaging
implementation available can be just to 'install the plugin XXX'.

The problem I have with a static list of plugins is that plugins are not
static, nor universal. Some plugins only work on windows. Some are
internal to company X. Some are too low in quality for us to want to
recommend them as blessed, but still exist. Plugins get updated
asynchronously from bzr itself, and sometimes don't get updated. We
shouldn't recommend a plugin FOO to be installed for bzr 1.3 when it
hasn't been updated for 1.3 - but often the update will occur after the
1.3 release. Updating a .py file in the installed tree is impossible for
normal users of a binary packaged bzr. A dynamic directory with a cache
file updated from bazaar-vcs.org seems sane to me and able to avoid
problems. We can have versions of that file for each release of bzr; or
we can have version data in the file. And we can choose to ship a copy
of the relevant file-version at the time the release is made. (Using
a .py file is inappropriate as it is executable code).

So I _firmly_ believe that we should not ship a static directory service
that distributors will need to remove - we should ship something that
everyone can use, or it should be optionally *added* in not removed.

In particular, I don't think we should put stuff that is in the core in
the core rather than in bzrlib/plugins/STUFF. If something is
sufficiently important to be part of the primary source tree, we should
treat it as part of the core.

I'd like to see the 'bzr-1.x.tar.gz' etc releases containing more than
just bzr's core - things like bzrtools, and bisect, are things we know
many users will want. We can script creating a combined tree quite
easily. If we do that we can avoid having conceptually problematic
implementations of things like the directory service in the core.


-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080219/e09a90f0/attachment.pgp