To sum up: If people would have known about this page this thread would have been shorter: http://vim-wiki.mawercer.de/wiki/topic/vim%20plugin%20managment.html (just add your own comments if you think the article is incomplete, you can edit without registering)
I'd like to remind that I posted some time ago about whether anybody would mind me making users work (such as such wiki) more visible, no replies. We do not only have a problem about "plugin managers", its a problem about managing community, about making vim.sf.net the best source of knowledge (collaboratively) - the community failed on this for 30 years. vim.sf.net is outdated (in some regards). This lead to eg Shougo potentially 'starting NeoBundle' missing VAM - thus one reason why we have 3 to 4 popular plugin managers now. Anyway NeoBundle implements "parallel installing" - something I never had time for to implement because it adds tons of issues which could go wrong (IMHO). I agree on - diversity is nice - the more the merrier but there is also one important resource in life: your time. The more the merrier the more time you'll need to evaluate, throw away and try something else. We as community should try to serve the user. The management of the community fails - which is why I'm that glad that the experiment "NeoVim" is taking place (hoping that such issues get fixed there). And that experiment makes me stop working on any plugin solution at the moment till its more clear how things turn out. People say "vundle is easy". The truth is: Many patches got bitrotted and where never merged. Some weeks ago I reviewed "all" issues - and even found trivial bugs such as "on windows it should be vimfiles" to to three times reported. Collaboration doesn't make sense / because if I contributed to Vundle I'd turn it into VAM. I offered using VAM's engine, this idea was disregarded by gmaric (which is fine). Details here (a lot of such issues got closed then): https://github.com/gmarik/Vundle.vim/issues/241 https://github.com/gmarik/Vundle.vim/issues/388 (why isn't vundle declarative ?) NeoBundle "fixed" this by adding a command meaning "make sure things are there and can be activated" Because Vundle is not declarative Vim's behaviour depends on whether you installed a plugin or not. If a plugin is missing Vim will startup silently. Whether this is what you want or not depends on you. I accept that there are many managers - I'd like to help people find the right tool. Things which got suggested on mailinglist: use github search only. This may lead to users finding outdated plugins which got starred in the past (eg Sanders snipmate) which were taken over after 1-2 years of no reply by the maintainer and is now "maintained" by 2-3 people from the community. Whatever solution exists - it should not force anything on the user, but guide him. This is what vim-pi is about. vim-pi tries to be the one missing source of plugins: https://bitbucket.org/vimcommunity/vim-pi and tell people if a plugin is outdated for any reasons. Anyway situation is as is - which is why I at least thought we could try to provide a common interface so that at least install instructions could be shared https://bitbucket.org/vimcommunity/vim-pi/issue/91/common-interface-for-most-plugin-managers Nobody really tried to join. The idea was that people can have a :InstallPlugin name {options} command for their .vimrc. Now that NeoBundle is being worked on situation got more complex, more investment doesn't make sense. Let me reply to some more random comments: @ping song > plugin manager build into Vim / VimL only Vim is "retarded" in the sense that its backward compatible (its a feature, too !). However plugins and maintainers evolve faster than people are updating VIMRUNTIME (The experiment splititng VIMRUNTIME off would be fun, too). But for VAM I would have been against making it official always because I wanted to allow updating it. Looking at history, which package manager should have been default? Again try to read up about a rough sketch of the history here: http://vim-wiki.mawercer.de/wiki/topic/vim%20plugin%20managment.html pathogen, VAM, Vundle, NeoBundle - which one? There is a "official plugin manager" called 'vimball' and GetLatestVimScripts For this reason I feel a manager should not be official - unless there is a clear winner for clear reasons. Vundle has many users - but I don't think its the best solution because its not declarative. (my view) But there are more issues: How to install plugins on Windows - eg installig git is a pain (kind of). http://vam.mawercer.de/ is one solution to just get the code by making my v-server fetch the plugins. Using ".zip" dowloading would be another solution (which VAM actually does implement). But then you still need 7zip or unzip or such (again VAM tries hard about just getting it right). unzip/git like tools could be provided by "plugins" which can be installed or by cygwin or msys like environments on Windows. There was not enough interest to make me or ZyX spend more time on this Windows topic. Also there are hard/soft dependencies. hard (required), soft:optional. How to encode this? Right now I think soft dependencies should be installed by the user explicitly. VAM introduced "addon-info.json" - a not very well defined format to declare dependencies. (without knowing what is really useful upfront it looked sensible to allow format people can add their own keys to). How important is "version lock". For VAM in the past I thought that just using latest versions is good enough - and reduces overall dev time - because there is only one combination of plugins to take care of. We've prepared allowing passing git hashes or such - but didn't finish the checkout implementation (lack of interest) - doing so would be trivial. For Vundle there have been PRs for years (see link above) which never got merged, NeoBundle checkout specific versions. The most important question is: How perfect do we want to be ? @Israel Chauca VAM does not install plugin if it already exists, thus you can put anything into vim-addons/foo and make VAM behave like pathogen by asking it to activate foo. If it happens to be a git repository you'll be able to update it. Thus simulating Pathogen by VAM is trivial. VAM also has (unfinished) Vundle emulation. - Individual plugins can be temporarily disabled by filtering them out of the runtimepath at start up. Why take the burden to filter the runtimepath? In Vam you just don't activate them. EG " VAMActivate this-plugin because the line is commented everything will work as expected. For Pathogen people have code in their .vimrc to recreate helptags always because Pathogen does'nt know when a plugin got updated. Many small reasons to think about whether VAM/NeoBundle would serve the user better. (my view) > canonical source for plugins, vim-pi tries to be one And no, vim-scripts is not an option because it cannot disambiguate plugins having same name but different ids. Bug has been filed but never fixed long time ago. Last but not least I don't want everybody to adopt VAM or NeoBundle. I want to make it easier for users to find their own solution by telling them about differences (which is why I started vim-wiki - everybody can edit it on disk, its just a git repository). I've sent an email some time ago about making such "wikis" more visible, not many replies. So in the end I got depressed. The key is managing the community better / and collaborating on the important things. Right now this means at least watch NeoVim eventually. Sorry that there is no easy answer to this topic. Marc Weber -- -- 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.
