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 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