-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Comments
I guess main problem is
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. |
Uhmm! I have reread vundle description: TODOS:
So this vundle.info file could help to solve not just this issue, but many other wanted features. |
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 |
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 |
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.
but it would be good to fix 1. and 2., too. |
|
- 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
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. |
@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. |
@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). |
Apologies, I miss interpreted what you were getting at with "pullrequests seem to be piling up in this repo". |
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... |
@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 |
Actually, since we do more than just registering in that function, I'll leave it with the current name. |
Please see #586 |
@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. |
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
To Reproduce
In a clean user system (no
.vimrc
,.gvimrc
, or.vim/
):cd $HOME
mkdir -p .vim/bundle
cd .vim/bundle
git clone [email protected]:gmarik/Vundle.vim.git
cd $HOME
.vimrc
with the minirc.vim (see below):PluginList
github-search.vim
linei
minirc.vim
The text was updated successfully, but these errors were encountered: