On Sunday, March 23, 2014 7:34:19 PM UTC+4, Bram Moolenaar wrote:
> At some point Vim started supporting plugins. At that time it was fine
> to add a plugin manually, it was a one-time thing. But now that there
> are so many plugins and they get updated often, manually updating
> plugins has become tedious.
>
> I am wondering what Vim users like about plugin managers.
> Is there one that works best, that everybody should use?
> Are there still features that no existing plugin manager offers?
>
> Vundle appears to be popular, someone mentioned it's better than
> Pathogen. So nobody is using Pathogen?
>
> But then there is also NeoBundle. But not everybody has git installed
> and it depends on that.
>
> And there also is vim-addon-manager. And Vimball.
>
> Is it fine to have a choice of plugin managers, or is this causing a
> headache (for users and/or for plugin writers). If yes, then we should
> pick one plugin manager and retire the others.
You are mixing entities here. Vundle, NeoBundle and vim-addon-manager are plugin
managers. I.e. they are able to take tasks of installing, updating, configuring
and removing plugins. (List is from wikipedia definition of a package manager.)
Pathogen cannot install, update or configure anything. It is not a plugin
manager. It allows runtimepath manipulations and has some code to open files in
installed plugins, but that's all. If you want a plugin manager you should
retire pathogen from discussion.
Vimball is missing update and configure features from the list. It is just an
archiving tool with unexpected functionality of recording installed files and
removing them by one command. Latter functionality is incomplete: it will leave
empty directories. So I would retire it from discussion as well. But definitely
not retire completely.
> But then there is also NeoBundle. But not everybody has git installed
> and it depends on that.
It is Vundle which requires git and only git. I do not know the current status,
but NeoBundle did have support for other VCS systems. Author also was doing some
work on integrating it with https://bitbucket.org/vimcommunity/vim-pi (which is
plugin index), though halted because I switched my efforts on NeoVim project as
it seems to be more urgent. Do not know what is the current state of this
support and whether you can use NeoBundle without git.
> I am wondering what Vim users like about plugin managers.
> Is there one that works best, that everybody should use?
> Are there still features that no existing plugin manager offers?
If you take package manager from almost any other project (e.g. pip (python),
luarocks (lua), gem (ruby), etc; not saying about package managers that are used
in linux distributions) you will see that current plugin managers lack
1. Support for installing exact versions of the plugins.
2. Support for dependencies with accepted version range.
3. Support for installing system-wide or in user directory. VAM has some sort of
it, but to use it you must first configure the target directory and only then
install it there. Nothing like `:InstallAddons --local` (with default
system-wide) or `:InstallAddons --system` (with default user-local).
4. Support for things like virtual environments.
5. (Only applicable for PM already managed in the topic, some do support it.)
Installing software not in a separate folders.
You may find comparison table in
http://vimpluginloader.sourceforge.net/doc/vim-addon-manager-additional-documentation.txt.html#VAM-comparison.
Beware: it may be outdated though.
After reading this comparison you will see though that NeoBundle is the best
plugin manager out there (the only minus "Dependencies are specified in the
vimrc, not in the installed plugin." is going to be erased once vim-pi support
will be ready). Note that the author of comparison (me) did not actually used
NeoBundle, only read its help. Its competitor though is not appropriate for
being Vim official plugin manager in the current stage due to its development
cycle (@MarcWeber uses "experimental programming" and no releases. I did not
like the idea, but I am not the author.). I hope he will appear here and comment
the situation: it would be good if a plugin manager I am a co-author of will
appear in main tree.
--------------------------------------------------------------------------------
One thing about the topic: do you really want a *poll* **right now**? I think it
is best to formulate requirements to the plugin manager, collect the responses
of the authors of existing plugin managers and then decide how to go further on.
Most likely after formulating the requirements most of the variants will be
automatically retired and other variants will be comparable enough to actually
launch a poll.
A list of things I would expect from a plugin manager:
1. Installing plugins in a FHS-compatible fashion (i.e. in
/usr/share/vimfiles/…). Target directory must be configurable. Reason: to
respect package maintainers from various distributions and do not make them
duplicate installing functionality on their end.
2. Outputting dependency list in a standard way. Reason: to make tools like
`g-cpan` (automatically generates Gentoo ebuilds for perl packages) able to
exist. It again prevents duplicating work on a distribution maintainers side.
3. Exact versions installation and dependencies with versions. Reason: new
versions of plugins may be incompatible with dependent plugins, or may have
some functionality removed. Low priority, because usually there are no
compatibility problems if you just use latest versions of all plugins.
4. Ability to recognize presence of plugins that were not installed by itself or
some index of installed packages with an official API functions to manipulate
it. Reason: make it able to mix system-wide installed plugins and user-local
installations, assuming system-wide will be installed by system plugin
manager; it also enables distribution maintainers to just rely on plugin
manager to install required plugin.
5. Ability to ignore package dependencies. Reason: overlaps with 4: enable
distribution maintainer to just rely on plugin manager and on the fact that
it under no circumstances will fetch unwanted dependency so it won't leak in
the binary package.
---
6. Ability to install plugins to a separate directory. Reason: for user it is
easy to find which files relate to which plugin.
7. Ability to update plugins without changing installation directory, ignoring
system-wide (if invoked from regular user) or user-local (if invoked from
root) installation updates. Reason: centralized updates are convenient.
8. Ability to track and preserve user changes to installed plugins or ability to
halt updating process if files were modified. Reason: some plugins expect
users to configure them in the same directory they are located in (example:
snipmate) or are simply not configurable.
9. Ability to run certain code on plugin installation and update. Possibly also
during uninstallation. Reason: some plugins require building of their C code,
some simply have incorrect directory structure so that it is needed to copy
files.
10. Ability to work with all kinds of sources present on www.vim.org. Reason:
you cannot really expect plugin authors to massively change archive types.
11. Ability to work with VCS sources. Reason: some plugins are available only
from github, some have useful features that were not released yet.
12. Ability to remove plugins. Reason: centralized removal is convenient as
well. Low priority.
13. Ability to list and remove unused plugins. Reason: it is just convenient.
Low priority.
---
14. Ability to specify location where to download sources and where to take
downloaded sources from. Reason: if user has spoiled installation make it
easy and fast to reinstall, if user has no Internet connection make it
possible to install. Low priority.
15. Ability to list URLs to download (possibly in a shell script). Reason: if
user has no Internet connection make it still some sort of usable. Low
priority.
--
--
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.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment