Be more tolerant about plugin name conflicts

[malcolmr]

Adding two plugins with the same canonical name to &rtp breaks Maktaba's plugin detection completely, reporting e.g.

Error detected while processing function maktaba#plugin#Detect[2]..maktaba#plugin#GetOrInstall:
line   11:
E605: Exception not caught: ERROR(AlreadyExists): Conflict for plugin "foo": foo/ and foo.vim/

However, it seems like we should be able to deal with this more tolerantly and ignore the second one, not just completely fail.

(The real case I'm looking at is using both https://github.com/junegunn/fzf and https://github.com/junegunn/fzf.vim, which seems reasonable.)

[mushanyoung]

+1

[shehabk]

+1, is the issue resolved ?

[dbarnett]

Nope! We have more projects than contributors so progress is slow.

As a workaround, you could add an addon-info.json file to one of hte plugins to give it a different unique name. For instance, in the case of fzf.vim, the plugin name is supposed to include the ".vim", so we can explicitly configure the name as "fzf.vim":

echo '{ "name": "fzf.vim" }' > fzf.vim/addon-info.json

Longer term, @malcolmr, WDYT about making it never fail but in the general case append a unique numeric index? Example:

Plug 'whatever/foo'
Plug 'yet-another/foo
echo maktaba#plugin#RegisteredPlugins()

Would print: ['foo', 'foo2']

We could also make smarter heuristics for guessing plugin names so that if you already have "fzf" installed and then install "fzf.vim", it'll keep the full name "fzf.vim", but that'll probably end up being order-dependent behavior and sometimes giving you "fzf" and "fzf2".

[shehabk]

Thanks @dbarnett , the workaround works for me.

[malcolmr]

Yes, fzf.vim adding an adding an addon-info.json would fix this specific case.

In general: sounds like that uniquifying the plugin name might work. It would mean that maktaba#plugin#Get() would be effectively non-functional for any conflicting plugins, so you'd have to be careful about plugin load order: if you had one plugin that was Maktaba-aware, it'd need to be found first so it got the 'correct' name.

(In this case I guess we're mostly talking about plugins that aren't aware of Maktaba at all(?), so nobody would be calling maktaba#plugin#Get()(?).)

I note that this behaviour is actually documented; see https://github.com/google/vim-maktaba/blob/ec7a094/autoload/maktaba/plugin.vim#L304-L307.

[dbarnett]

Hmm, now that you mention it, generally you won't have conflicting plugins that are both using maktaba, and plugins do assume they'll be able to look up their own plugin object by plugin name. Preferably a plugin that doesn't use maktaba at all wouldn't conflict with a maktaba plugin at all.

What about if we make a "soft"/lazy registration for plugins without an explicit name? Then we'd only try to disambiguate when you access the plugin object via maktaba#plugin#Enter or maktaba#plugin#Get. Still some corner cases there to think through, but the code would be able to make a much more informed decision if it resolved ties later in the process.

[malcolmr]

That sounds reasonable, I think. Certainly I agree with the principle that non-Maktaba-using plugins shouldn't conflict with anything, if possible.

(Also, we can add maktaba#extension#GetRegistry(name) as an example of something where the caller expects to be able to predict the plugin name from outside.)

[dbarnett]

Yep, but plugin name references from the outside don't help disambiguate, so these implicit strategies might still run into an unavoidable conflict if something looks up the plugin from the outside before the right plugin initializes.