8

On Debian based systems, there is a package named vim-addon-manager.

My understanding is that it allows to install some plugins based on a repository of available plugins. To be able to install them, the plugins have to be packaged and pushed to the debian repos.

I don't understand the point of this package because it seems much less flexible than the other plugin managers which allows to install any plugin from github, a git repo or even a local folder, which allow parallel installation, lazy-loading, etc...

In the first place I thought that the package was an old solution created before the other plugin managers and more or less deprecated, but its git repo seems to indicate that its development is still active.

So my questions are:

  • Is there other differences than the available plugins betwwen vim-addon-manager and the other plugin managers? And if so, which differences?
  • Are the packages and the other managers meant for the same purpose or are they complementary
  • In which use-case is it more convenient to use the package instead of the other plugins?

Note that my question is inspired by this one but here I am not asking how to use the package, but rather why would someone need it.

15

N.B., I'm one of the original authors of Debian's vim-addon-manager (which I'll refer to as dvam for the rest of this answer, to avoid confusion with Marc Weber's vam).

dvam is intended solely to manage addons that are distributed in the form of Debian packages. There are people that prefer, for various reason, to use packaged software even for things like Vim addons, instead of getting the software directly from upstream.

In the broader sense, yes dvam and more general tools like plug, vundle, etc. are meant for the same purpose -- providing a mechanism for enabling the use of certain addons in your Vim environment. They are targeting different use cases, though, and can be used to complement each other.

dvam intends to give a user of a Debian-based system control over which packaged addons are enabled, both system-wide and for a specific user. That is, it tries to solve the use cases of a sysadmin installing and enabling a packaged addon in the system-wide config but allowing the user to disable it, as well as the reverse (enabling an addon that's disabled in the system-wide config).

There are some warts in the way Debian's tool was initially designed (symlinking individual files rather than working on directory like pathogen does) which haven't fully been addressed yet. I've been dragging my feet on fixing that, but should revisit it to see if Vim's new 'packpath'/:packadd features help me with that at all.

  • That's pretty cool to have an explanation by of the author, thanks! I understand better the origin of the tool. The use case of the sysadmin that you mentioned seems pretty obvious, now I wonder why I didn't think about it in the first place. Thank you for your answer. – statox Apr 8 '16 at 14:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.