I've made a small (pathname) error in my answer, see the correction below. ----- Mail original ----- > De: "Luc Hermitte" <hermi...@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, sash...@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
