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 [email protected]. For more options, visit https://groups.google.com/d/optout.
