standard way include plugin as a dependency of another plugin

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

standard way include plugin as a dependency of another plugin

Sashan Govender
Hi

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?

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Lifepillar
On 30/07/2017 04:40, [hidden email] 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 <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?

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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

lith
In reply to this post by Sashan Govender
> 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>

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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

hermitte
In reply to this post by Lifepillar
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, [hidden email] 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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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

----- Mail original -----

> De: "Luc Hermitte" <[hidden email]>
> À: "vim use" <[hidden email]>
> 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, [hidden email] 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 [hidden email].
> 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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Loading...