Error on install from interactive mode

[sukima]

Processing 'gmarik/github-search.vim'
Error detected while processing function vundle#installer#run..vundle#installer#install_and_require..vundle#config#bundle..<SNR>8_check_bundle_name:
line    2:
Vundle error: Name collision for Plugin gmarik/github-search.vim. Plugin gmarik/github-search.vim previously used the name "github-search.vim". Skippin
g Plugin gmarik/github-search.vim.
Error detected while processing function vundle#installer#run..vundle#installer#install_and_require..vundle#installer#helptags:
line    1:
E121: Undefined variable: rtpath

To Reproduce

In a clean user system (no .vimrc, .gvimrc, or .vim/):

1. cd $HOME
2. mkdir -p .vim/bundle
3. cd .vim/bundle
4. git clone git@github.com:gmarik/Vundle.vim.git
5. cd $HOME
6. Edit .vimrc with the minirc.vim (see below)
7. Run vim and execute command: :PluginList
8. Move cursor to the github-search.vim line
9. Press the letter i

   minirc.vim

set nocompatible
syntax on
filetype off
set rtp+=~/.vim/bundle/Vundle.vim/
call vundle#begin()
Plugin 'gmarik/Vundle.vim'
Plugin 'gmarik/github-search.vim'
call vundle#end()
filetype plugin indent on

[albfan]

I guess main problem is Name collision because I'm facing the same problem trying wrongly to install an already installed plugin.

Pluginsearch: might detect this cases and mark searches as i installed.

  Search results for: foo
  Plugin 'MarkdownFootnotes'
i Plugin 'VimFootnotes'
  Plugin 'foo.vim'

About forks, don't know if this is a wrong direction for the sake of simplicity but plugin repos could incorporate some metadata in an optional file vundle.info

name: Foo
version: 1.2
short description: A plugin for foo
long description: This plugin tries to do foo by ...
changelog:
  - 1.2: |
replace foo with bar
adding i18n
  - 1.1: |
adding foo
  - 1.0: |
first version
tags: 
  - foo
  - bar

This will help making searches and take a brief look to new plugins.

[albfan]

Uhmm! I have reread vundle description:

TODOS:

• allow specifying revision/version?
• handle dependencies
• show description in search results
• search by description as well

So this vundle.info file could help to solve not just this issue, but many other wanted features.

[sukima]

Although it is a common pattern to include a package management metadata file and many package managers do it. I'd be a little hesitant to require all VIM script authors to be aware of and implement such a file. I'd also look for solutions that would degrade gracefully for non-Vundle / missing vundle.json (or yml if really needed :grin: ) file.

[albfan]

Yeah. I don't like to add another file to plugin develop, so an approach like vim modeline can be used. That way, developers have a flexible way to provide extra metadata (in first comments or in vundle.json or no metadata)

But seeing as a win-win option (easy for vundle manager to read, easy for developers to maintain metadata) I suppose by the time everyone will choose the additional file.

Going back to this opened issue, any clue to detect forks, or already installed plugins? is this the problem underneath Name collision error?

[clausreinke]

Ran into this myself: the intention behind the error seems to be avoiding name clashes in the directories used to install the plugins, if different plugin specifiers happen to resolve to the same short name. Unfortunately, there is no check whether a previously registered short name belongs to another occurrence of the same plugin specifier.

1. s:check_bundle_name should really be named s:register_bundle_name - it has the side-effect of updating the bundle name registry
2. vundle#config#bundle shortcuts without result if s:check_bundle_name fails, but vundle#installer#install_and_require keeps calling vundle#installer#helptags anyway, which then complains about the invalid bundles it is given
3. the immediate fix for this issue is simple: add another condition to s:check_bundle_name

 funct! s:check_bundle_name(bundle)
   if has_key(s:bundle_names, a:bundle.name)
+    \ && s:bundle_names[a:bundle.name]!=a:bundle.name_spec
     echoerr 'Vundle error: Name collision for Plugin ' . a:bundle.name_spec .
           \ '. Plugin ' . s:bundle_names[a:bundle.name] .
           \ ' previously used the name "' . a:bundle.name . '"' .

but it would be good to fix 1. and 2., too.

[peterdachuan]

在 2015年3月31日，上午12:18，Claus Reinke notifications@github.com 写道：

Ran into this myself: the intention behind the error seems to be avoiding name clashes in the directories used to install the plugins, if different plugin specifiers happen to resolve to the same short name. Unfortunately, there is no check whether a previously registered short name belongs to another occurrence of the same plugin specifier.

s:check_bundle_name should really be named s:register_bundle_name - it has the side-effect of updating the bundle name registry

vundle#config#bundle shortcuts without result if s:check_bundle_name fails, but vundle#installer#install_and_require keeps calling vundle#installer#helptags anyway, which then complains about the invalid bundles it is given

the immediate fix for this issue is simple: add another condition to s:check_bundle_name

funct! s:check_bundle_name(bundle) if has_key(s:bundle_names, a:bundle.name)

• \ && s:bundle_names[a:bundle.name]!=a:bundle.name_spec echoerr 'Vundle error: Name collision for Plugin ' . a:bundle.name_spec . \ '. Plugin ' . s:bundle_names[a:bundle.name] . \ ' previously used the name "' . a:bundle.name . '"' . but it would be good to fix 1. and 2., too.

— Reply to this email directly or view it on GitHub https://github.com/gmarik/Vundle.vim/issues/509#issuecomment-87740162.

Very glad to receive your solution! However, I’m a newer to macVim, and have just plug-in ctags, winmanager, and taglist without vundle. Your solution is too hard for me to understand now. I would keep on studying, hoping your solution would help me in the near future. Thank you all the same!

[clausreinke]

see https://github.com/clausreinke/Vundle.vim/tree/collected_fixes for my collected fixes so far, and let me know whether this fixes or breaks things;-)

also, how to proceed? pullrequests seem to be piling up in this repo. I understand if the owner doesn't always have time himself, but I don't know who to ping otherwise.

[sukima]

@clausreinke I install Vundle via git from a shell script so I'm not tied to this repo. If you were to maintain a fork then switching is easy (for me) and you could maintain pull requests better. Hopefully, others will see this issue and know to switch.

[clausreinke]

@sukima that is not my intention:-) as far as i understand, the author has helpers, so i just need to get the attention of one of those, then use my fork to prepare a pull request. There are too many plugin managers already. using the fork directly is just a temporary workaround (and allows for testing).

[sukima]

Apologies, I miss interpreted what you were getting at with "pullrequests seem to be piling up in this repo".

[jdevera]

I get notifications for all comments in issues but I end up reading them on my phone while commuting. I try to help people with problems that are easy to fix but unfortunately between work and family I get very little time at the computer to look at more complex issues. Additionally, I don't use windows and we currently don't have any active collaborator who does, so merging pull requests has an even higher risk for windows users.

We do say we need help, and help comes and goes, and AFAIK the most recently active windows guy who was working with us switched to some other tool and disappeared from the repo.

So I still try, but I have only about 2 hours each month to work on Vundle while I'm at the computer. So imagine the rate at which I can process stuff...

[jdevera]

@clausreinke I'm looking now at your comment and I think you are right in all 3 points. However, when looking at the condition itself I think it would be more solid to compare the resolved URIs for both instead of just the specs, since Align and vim-scripts/Align are still the same Plugin, despite their different specs.

[jdevera]

Actually, since we do more than just registering in that function, I'll leave it with the current name.

[jdevera]

Please see #586

[clausreinke]

@jdevera thanks for looking into this. Good to hear that someone with commit access is listening to all issues, even if you can't allocate much time.

Sorry to hear about the general situation. I know from other software how quickly the windows version can fail if all contributors are unix-only.