Dependency issue with Markdown and snipmate

[mikl]

I was cleaning out my installed bundles, noticing I had two instances of snipmate (snipmate and snipMate). I deleted both to let VAM sort out the correct one to install. Now, I'm greeted with this when I start vim:

% vim README.md 
Plugin Name: snipMate ver. 
Script Nr: 2540
dependency chain: snipMate < Markdown
Target: /home/mikl/.dotfiles.git/vim/managed-addons/snipMate
!> Deprecation warning package snipMate:
snipMate is an alias to snipmate now - so use 'snipmate'
Origin: git git://github.com/MarcWeber/snipmate.vim
Plugin snipMate is deprecated, see warning above. Install it?
[N]o, Ye(s):

Only way to get this to go away is to have two copies of snipmate, and that might cause problems elsewhere. Can we mitigate this somehow?

[MarcWeber]

Quick fix: edit the plugin-info.json (which should be called addon-info today, but thats not important) and just patch the name manually. Ugly, but works.

Longer fix: Write the author to change it.

Even longer fix: Write a patch phase for VAM (overkill if author replies in a timely manner)

Great that

• the output of VAM is that great that people start using it for bug reports
• great that foreign people start using the dependency system

Looks like finally my dreams (making plugin management suckles) gets true.

I'll write the author. Thanks for reporting

[ZyX-I]

I believe for things that already require loading VAM-kr it should be allowed to use “%SNR” notation, because script number is the only thing that won’t really ever change. For addon-info.txt this will lead to overwriting it though, cycle should be the following: check for exact match, check for %SNR presence (or vim_script_nr key in dependency information), expand it if there is any, check generated name for being equal to original, overwrite if it is not. Don’t allow meaningless %SNR directories, it would be a great step backward.

[MarcWeber]

Excerpts from ZyX-I's message of Wed May 02 21:38:30 +0200 2012:

I believe for things that already require loading VAM-kr it should be allowed to use “%SNR” notation, because script number is the only thing that won’t really ever change. Assuming that you want to use "old" ids. Sometimes upstream changes (eg snipmate) - then you can keep the name and use a new id. I don't know which happens more often. I know that names are much more readable than ids. If there are many hints that noise about renaming gets too much - we can talk about changing it. But I don't see that happening right now.

I'm fine with adding it as suggestion to the bug section to give people a chance to tell us that they want this to be implemented sooner.

[MarcWeber]

This bug is obsolete because github.com/MarcWeber/ultisnips can also read snipmate-snippetsn now. For that reason it does no longer make sense to have snipmate-snippets fetch snipmate. Thus you have to install the engine and the snippets yourself. If there is another similar use case we will have to talk about a nice fix again.