Handle repeated vim-scripts plugin names

[fisadev]

The mechanism to install plugins from vim.org/scripts uses the name of the plugin as identifier, but there are many repeated names of plugins. There is no way to diferentiate one plugin from another with the same name. Some examples with :BundleSearch python.vim

[gmarik]

hey @fisadev, thanks for letting me know about this It's not Vundle's issue rather vim-scraper is adding duplicates into plugin list.

[fisadev]

Ok, I'll see if I can help with vim-scrapper then, because this is halting the release of the brand new ultra-magic vundle based version of my vim config :) (vundle based branch on https://github.com/fisadev/fisa-vim-config/tree/develop )

[gmarik]

@fisadev forgot to mention that i'll look into vim-scraper to why we get duplicates...)

[fisadev]

but there are not "duplicates". There are different plugins with the same name :/ Examples: http://www.vim.org/scripts/script.php?script_id=790 http://www.vim.org/scripts/script.php?script_id=477 http://www.vim.org/scripts/script.php?script_id=30

[Xerkus]

issue with plugin name collisions resolved as side effect of refactoring for #35 my branch: https://github.com/Xerkus/vundle/tree/feature/refactor-git-treeish-support Example: Bundle 'rstacruz/sparkup as sparky'

but i think i missed key part of vundle as i've only seen installation from git and it looks like scripts repository from vim.org is not git based

[gmarik]

@fisadev vim-scraper automatically resolves name conflicts for plugins with same name(as github doesn't allow duplicate repos) But apparently something isn't working as expected

[gonzaloserrano]

Hi! How does it resolve it?

I wan't to use this plugin called "Mark" http://www.vim.org/scripts/script.php?script_id=2666 which it's a continuation of this one http://www.vim.org/scripts/script.php?script_id=1238 (deprecated) but looks like the scrapper is getting the old one.

Any hints?

[afranke]

I'm hit by this as well. I'd like to install http://www.vim.org/scripts/script.php?script_id=2530 but using po.vim doesn't work as the name is not unique.

[MarcWeber]

related to #323

[MarcWeber]

This is the related vim scraper bug https://github.com/vim-scraper/vim-scraper/issues/65

[BatmanAoD]

@MarcWeber says (in vim-scraper/vim-scraper#65) that the scraper should be replaced with https://bitbucket.org/vimcommunity/vim-pi somehow. @gmarik, any idea how easy this would be to implement?

[gmarik]

@BatmanAoD if he knows that it "should be replaced" ask him how to do it…

[BatmanAoD]

Sorry, I didn't provide the full path to the discussion. His comment was not quite as helpful as I think it should have been, but hopefully he'll clarify.

[MarcWeber]

gmarik: I've been very clear: If I'd start contributing to vundle or vim-scripts I'd turn this all into something I already have. And thanks again for showing me how important it is to have a nice README.md file!!! :) AFAIK the scraping script's task is to find "updates" and "script uploads". This requires parsing either the front page or the longer list of "recent changes", or even worse: all plugin pages (a lot of traffic). If something goes down for whatever reason its more likely that anything gets missed. The script-info.php file does exactly one thing: It dumps database contents from www.vim.org. Thus it includes all important data about all plugins. If you diff a new dump with an older dump you have exactly what you want: a list of plugins to update without writing a scraper. I agree that others may think differently, eg that writing a scraper is easier than writing a diff algorithm on a list of plugins. Potentially there are more inconsistencies such as "humans" deleting versions (eg due to spamming) - which might or might not appear on the vim.sf.net change log (I never analyzed the code). Of course as always its my view. I personally delay all work till I understand what neovim will turn into. I feel that www.vim.org's plugin list is outdated - and fixing it would require even more hacks (such as external apis) because PHP on vim.sf.net cannot query github api for instance. Eg the "next generation plugin page" should be satisfied by users submitting github urls (without uploaads) - and just show README.md instead of install/usage instructions which is causing too much duplication. Maybe we can find a common shared and commonly maintained upstream in the forseeable future causing wealth to all users. The rating system found at vim.sf.net is not very helpful. Eg VAM was downvoted just because I uploaded a .txt file telling users "goto github to get latest version" - the problem is: This was told me on the mailinglist by accident 2 years later! Healthy projects have a short feedback loop which vim.sf.net doesn't provide.

I hope its more clear now what I've been talking about.

Thus instead of discussing this all we should consider creating a new manager based on lua eventually (serving neovim as common upstream) for the reasons I mentioned.

[gmarik]

MarcWever: that's not very clear by the way…

[Shougo]

Thus instead of discussing this all we should consider creating a new manager based on lua eventually (serving neovim as common upstream) for the reasons I mentioned.

Why we should rewrite it? I think it is too early. neovim is not stable product.

[MarcWeber]

I'm not talking about "rewriting it now" - but we should consider the case that neovim matures (fast) and competes with Vim - maybe even outperforms it. That's why I personally delay all work on any Vim plugin management solutions - because at least 3 solutions exist which work reasonably well. (Vundle, NeoBundle, VAM, Pathogen, ..). I say "could" because Shougo is right. Funding is at $30.000 (which is quite a lot for Brazil) - so chances are high that there is some continuity. Sry if I've been too vague still

[Shougo]

neovim is interesting product. It may be next generation of Vim. But, neovim still missing some important features.

Ex: plugin compatibilities, if_xxx supports, GUI.

So I cannot support it now.

[jdevera]

This is fixed in v0.10

If Vundle detects name collisions it will warn the user so they can use the "name" override to solve it,e.g.:

Plugin 'foo'
Plugin 'bar/foo', { 'name' : 'barfoo' }

[BatmanAoD]

@jdevera I'm seeing a name collision for coot/CRDispatcher and coot/EnchantedVim, which appear to me to be unique. However, I'm not seeing a name collision for Rename, which is not unique. What exactly is the expected behavior here?

....worse, even after putting { 'name' : 'CRDispatcher' } (and similar for EnchantedVim) on the "Bundle" lines for those plugins, I'm still getting the "Name collision" error on startup. Why is this?

[Shougo]

However, I'm not seeing a name collision for Rename, which is not unique. What exactly is the expected behavior here?

Yes, this feature cannot resolove it. So I think it is to be opened.

[BatmanAoD]

......and since Vundle doesn't allow picking which version of a Bundle to use, and I manage Vundle using Vundle itself, I'm apparently stuck (for now) with these erroneous error messages every time I open Vim.

[jdevera]

@BatmanAoD I just added these two lines to my vimrc:

Plugin 'coot/CRDispatcher'
Plugin 'coot/EnchantedVim'

And I'm not getting any errors. Do you have the lines repeated perhaps?

I'm not seeing a name collision for Rename

Please explain this, I don't understand what you mean. What is Rename?

[BatmanAoD]

@jdevera Ah. Yes, I did have the lines repeated, sorry.

Rename is the name of two separate Vim scripts, so it's a good test-case for Vundle's duplicate-resolution logic: http://www.vim.org/scripts/script.php?script_id=1928 http://www.vim.org/scripts/script.php?script_id=3525

1928 is the one the scraper finds, and fortunately, that's also the one I actually want. It's still a bug, though, I think. Unfortunately, I don't really see how it could be resolved within Vundle, since my understanding is that Vundle uses the git mirrors of vim scripts, and I don't think script 3525 has a git mirror.

[jdevera]

Ok I'll close this again. I guess the remaining problem is a scraper problem not Vundle's

[noscripter]

running into the same problem here with plugin Bundle 'groenewege/vim-less', url of which is http://github.com/groenewege/vim-less, wondering how to resolve this?

[lucc]

@leoshawn you should open a new issue for this and describe your problem more fully including a minimal vimrc and maybe the state of your ~/.vim/bundle directory.

[wmayner]

For anyone who's having this issue with the two python.vim bundles (here and here), Dmitry Vasiliev has made his python.vim available from this repo (per this tweet), so you can get it from there with Bundle 'hdima/python-syntax'.