Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error on install from interactive mode #509

Open
sukima opened this issue Aug 26, 2014 · 15 comments
Open

Error on install from interactive mode #509

sukima opened this issue Aug 26, 2014 · 15 comments

Comments

@sukima
Copy link
Contributor

sukima commented Aug 26, 2014

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 [email protected]: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
Copy link

albfan commented Sep 18, 2014

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

albfan commented Sep 20, 2014

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
Copy link
Contributor Author

sukima commented Sep 21, 2014

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 😁 ) file.

@albfan
Copy link

albfan commented Sep 21, 2014

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

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

在 2015年3月31日,上午12:18,Claus Reinke [email protected] 写道:

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 #509 (comment).

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 pushed a commit to clausreinke/Vundle.vim that referenced this issue Mar 31, 2015
- rename s:check_bundle_name to s:register_bundle_name,
  it has the side-effect of updating the bundle name registry
- expand possible return values
- re-registering a plugin name for the same bundle is no conflict
- don't continue processing plugins if registration fails
@clausreinke
Copy link

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
Copy link
Contributor Author

sukima commented Apr 1, 2015

@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
Copy link

@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
Copy link
Contributor Author

sukima commented Apr 1, 2015

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

@jdevera
Copy link
Contributor

jdevera commented Apr 1, 2015

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
Copy link
Contributor

jdevera commented Apr 4, 2015

@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
Copy link
Contributor

jdevera commented Apr 4, 2015

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

@jdevera jdevera self-assigned this Apr 4, 2015
@jdevera
Copy link
Contributor

jdevera commented Apr 4, 2015

Please see #586

@clausreinke
Copy link

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

jdevera added a commit that referenced this issue Apr 5, 2015
Name duplication is checked so that users don't end up overwriting one
plugin directory with the contents from another plugin that shares a
common name.

However, if the repeated plugin happens to be the same, there will be no
surprises and there is no need to flag this as an error. This needs if
particularly acute due to the fact that we currently don't show, in the
plugin search, which of the resulting plugins are already installed, so a
user might very well attempt to install a plugin they already have.

With this change, instead of seeing an error in this scenario, the user
will see a message indicating the plugin is already installed, and no
additional cloning will be performed.

Fixes #509
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants