Re: standard way include plugin as a dependency of another plugin

Hi,

(Sorry, it seems I've deleted the original message, and I'm not answering to the mail I should be answering to).

> On 30/07/2017 04:40, sashang@gmail.com wrote:
> > I'm writing a plugin and want it to depend on another plugin
> > installed. At the moment I just have a line
> >
> > source <path to plugin>
> >
> > in my plugin that pulls in that plugin. Is there a standard way of
> > doing this or do plugin authors just invent their own way? Could I
> > use Vundle here instead?


There is no standard way of proceeding. Also there are two sides to the question:
1- making sure what we depend upon is installed;
2- making sure what we depend upon is defined.

Beside the actual answer will depend on what you are actually depending upon.

1- Regarding availability
a- Most people simply document the dependency(/ies), and it's up to the end-users to make sure every dependency is properly installed.
In all cases, I consider that **documenting is mandatory**.


b- Some will use git submodules to make this as simple as possible.
The only, and main disadvantage, as Lifepillar said, is that a plugin may be installed several times. An incorrectly written plugin may even duplicate events. We could also experience very tricky bugs when several versions of a same plugin are installed.

IMO, this is not a good solution.


c- A few of us are specifying the dependencies for the only two plugin managers that support dependencies. I even go further and advocate their use. Unfortunately, the popular plugin managers are the simple ones, which don't understand dependencies so far.

The only two plugin managers that support dependencies (and that I'm aware of at this moment) are:
- VAM: https://github.com/MarcWeber/vim-addon-manager (through vim-py)
- VimFlavor: https://github.com/kana/vim-flavor

Even if you're not using them, nor expect to ever use them, I highly recommend that you specify the dependencies of your plugin for these two plugin managers. IOW, you'll have to define an addon-info.json file and a VimFlavor file -- unfortunately they don't share a common syntax. :(

You'll find plenty examples in my plugins. See for instance: https://github.com/LucHermitte/lh-brackets


d- Vim 8 packages don't solve anything. We can still have multiple versions of a same plugin installed (which is clumsy and bad), and they are not able to automatically install the dependencies.

If there was a notion of "environment" like we have in Python or conda, or of "sandbox" like with Haskell or nix, then may be we could have multiple packages that contain different versions of a same plugin. So far and AFAIK, this is not the case. Hence my current stance.



2- Regarding "sourcing"

a- Before Vim7, we had to source plugins where global functions, mappings, abbreviations, command, etc. were defined.

A simple way was to check for something we need, and if it isn't detected as defined, then we explicitly source the dependency.

if ! exists('*SomeGlobalFunction')
runtime plugin/MyDependencyThatDefineSomeGlobalFunction.vim
if ! exists('*SomeGlobalFunction')
echoerr "WARNING: MyDependencyThatDefineSomeGlobalFunction isn't installed. MyFooBar plugin is disabled. Please see xxxx"
endif
endif

Or if you don't care about sourcing something that may have already been sourced, you could simply type:

runtime plugin/MyDependencyThatDefineSomeGlobalFunction.vim
if ! exists('*SomeGlobalFunction')
echoerr "WARNING: MyDependencyThatDefineSomeGlobalFunction isn't installed. MyFooBar plugin is disabled. Please see xxxx"
endif

You could also check the plugin version in case it stores its version number in its `g:loaded_MyDependencyThatDefineSomeGlobalFunction` header-gate variable. This has been described in another answer.


(In case of definitions done in filetype plugins, what we had to do was a little bit trickier)


b- Now, we are past Vim 7. Vim 7 has introduced autoload plugins and their autoloaded functions.
Modern plugins will use autoload plugin files to store their functions. Most of the time this is just to speedup the starting time. Sometimes, this is because some of us are aware this is the best way to define libraries.

This time instead of checking whether a particular symbol is defined in order to source on the fly, we simply call the autoloaded functions. Given their name, foo#bar#func(), Vim will know that if the function doesn't exist then it must execute `:runtime foo/bar.vim`. If the function still doesn't exist, Vim will issue an error message.
Sometimes, you'll see a few issues from the users, of your plugin, that have skipped the installation procedure you have described in your plugin documentation.


Of course if you're not trying to execute a function defined in an autoload plugin file, you're back to square 2.a-.

Regards,
--
Luc Hermitte

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.