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

I've made a small (pathname) error in my answer, see the correction below.

----- Mail original -----
> De: "Luc Hermitte" <hermitte@free.fr>
> À: "vim use" <vim_use@googlegroups.com>
> Envoyé: Mardi 1 Août 2017 13:33:17
> Objet: 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`.

(EDIT: this is what is executed by Vim)
`:runtime autoload/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.
>

--
--
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.