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" <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
> > >
> > > 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 "
> 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 "
> 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
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
> >
> > 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 "
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 "
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
Re: standard way include plugin as a dependency of another plugin
> I'm writing a plugin and want it to depend on another plugin installed. At
> the moment I just have a line
>
> source
I sometimes use something like this:
if !exists('g:loaded_DEPENDENCY') || g:loaded_DEPENDENCY < 100
runtime plugin/DEPENDENCY.vim
if !exists('g:loaded_DEPENDENCY') || g:loaded_DEPENDENCY < 100
echoerr 'DEPENDENCY >= 1.00 is required'
finish
endif
endif
This makes sure plugin/DEPENDENCY.vim is loaded. The file has to be in the
runtimepath. This solution is suboptimal if g:loaded_DEPENDENCY < 100 though.
Regards
--
--
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.
Re: standard way include plugin as a dependency of another plugin
On 30/07/2017 04:40, sash...@gmail.com wrote: Hi I'm writing a plugin and want it to depend on another plugin installed. At the moment I just have a line source 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? I think that the usual solution is just to document the dependencies. Then, it is the user's responsibility to get them, manually or using a plugin manager. The "modern" way (aka, Vim 8) is to use packages. From `:h packages`: "A package can contain multiple plugins that depend on each other." If you do not have control over one or more of your dependencies (because they are plugins written by other people), and if you distribute your package as a Git repo, a possibility is to include the dependencies you need as Git submodules. Mind that using submodules might result in users having multiple copies of the same plugin (i.e., one from your package and one installed by the user elsewhere, or even by another package). Typically, it shouldn't do any harm, but it is something to keep in mind, at least until packages become a mature feature of Vim, and widely adopted by plugin developers (which has not been the case, so far), so that best practices will emerge. Life. -- -- 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.
standard way include plugin as a dependency of another plugin
Hi I'm writing a plugin and want it to depend on another plugin installed. At the moment I just have a line source 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? -- -- 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.
