[RFC/MERGE] Allow two plugins to register the same command.

[John Arbash Meinel]

Aaron Bentley wrote:
> Michael Ellerman wrote:
>>> On 5/31/06, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
>>>> So, the second one to be registered gets prefixed with the module name?
>>>>
>>>> That seems unpredictable to me.
> 
>>> Well it's unpredictable unless you have numbered names in your
>>> .bazaar/plugins. ie I have "01_shelf" and "02_bzrtools", so "shelve"
>>> is always from shelf and "bzrlib-plugins-bzrtools-shelve" is from the
>>> bzrtools version.
> 
> So I'm not sure that we load plugins in a sorted order.  I thought we
> just did 'os.list', which isn't always sorted.
> 
> Also, AIUI, the directory names are supposed to be 'shelf' and 'bzrtools'.

I feel like we should probably have some way of handling cases like
this, where we might have a global plugin, and a user wants to override it.

We do use 'os.listdir()' while we are finding plugins. But once we have
found them all, we do "plugin_names = list(plugin_names);
plugin_names.sort()".
And that is partially because we initially build them into a set, so
that we don't load something with the same name twice. (It helps in the
case you have a .py, .pyc and .pyo).

> 
>>> The disambiguate/alias idea is interesting, and might be preferable.
>>> It certainly gives more flexibility, and would work for people who
>>> don't have control of the plugin directories (possibly on a shared
>>> install of bzr eg.) I'll think about it.
> 
> Agreed.
> 
>>>> Also, perhaps it's worth allowing all commands to be specified using the
>>>> module name.
>>>
>>> Just for completeness? Or do you have a use case where that would be
>>> useful? I can't think of one.
> 
> Well, as a way to unambiguously specify a command.  If you're writing
> scripts that may be used on various machines, with different sets of
> plugins, using the full module command name would ensure that the script
> behaved properly on all of them.
> 
> Aaron

Except we still would expect things to be loaded into a particular
location. So if I install the plugin as 'bzrtools-ab'. Unless I miss
something about what Michael wrote, he should have 2 commands:
bzr shelve
and
bzr bzrlib-plugins-02_bzrtools-shelve

Also, the above plugin isn't strictly accessible from python. You can't
do "import bzrlib.plugins.02_bzrtools".

Because '02_bzrtools' is not a valid python variable.
You can do tools = __import__('bzrlib.plugins.02_bzrtools')
or tools = getattr(bzrlib.plugins, '02_bzrtools')

This came up a while ago, that Robert was thinking we may not want to
allow loading of plugins that aren't in valid python variable name
paths. I think a better solution is to have a plugin be able to define
its 'canonical' name, rather than just using the path it was loaded from.

In general, I'm -0 on having plugins automatically get their command
names decorated. But I do realize we need a way to solve the 2 plugins
providing the same commands issue. (My current method is that all
plugins I write are their own project, so I don't have the same
collection issue, but we shouldn't strictly require that).

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060530/2f92c1ce/attachment.pgp