Give more concrete example of adding a source

[gotgenes]

The documentation states

You can add your own sources to the pool easily (BUG/TODO [5]): >
  let g:vim_addon_manager = {}
  let g:vim_addon_manager.plugin_sources = {}
  let g:vim_addon_manager.plugin_sources['your_plugin_name'] = { plugin dictionary }
<

A more concrete example would be helpful, for instance,

let g:vim_addon_manager.plugin_sources['LustyJuggler'] = {'type': 'git', 'url': 'git://github.com/gotgenes/lusty', 'vim_script_nr': '2050'}

It would also be helpful if the documentation explicitly states that these lines need to be added to the .vimrc file. Also, am I correct in that these lines must be added prior to the call vam#ActivateAddons line? If so, this should be stated in the documentation, too.

[MarcWeber]

See latest commit. I tried improving documentation. However you just want to use the hacky name rewriting:

ActivateAddons(['github:gotgenes/lusty'])

In this particular case its complicated because the git repo contains two www.vim.org plugins, right?

Anyway it could just be submitted to VAM-kr - linking to script_nr is not possible because it must be linked to two script_nr(s) which VAM does not support (yet) - I don't want to add support for it.

Marc Weber

[gotgenes]

Yes, I agree, that example of LustyJuggler is not the best one, unfortunately. I agree with the one-plugin-per-repo philosophy. I'm pretty frustrated that sjbach uses the same git repo for both plugins. Ideally he should split the repo up into three, one for each of the Lusty plugins plus a third for a plugin that simply contains the library of common functions shared by both the actual plugins. Unfortunately as it is you get both the LustyJuggler and LustyExplorer activated when trying to activate just one with VAM. :-(

As far as the example I used, which was overriding the default Lusty repository, I chose to "override" it, rather than use the github-specifier approach, because VAM doesn't have a way of specifying that the github-specified plugin satisfies plugin dependencies. If you need to use a github repo to satisfy a plugin dependency, you have to hack the vim_addon_manager.plugin_sources dictionary. This is actually documented in the help documentation, but something I only discovered by accident (for a dependency of snipMate, maybe honza's snipmate-snippets if I recall correctly).

Thanks for documenting the method of writing the Pool function. That looks a little more elegant.

[ZyX-I]

Anyway it could just be submitted to VAM-kr - linking to script_nr is not possible because it must be linked to two script_nr(s) which VAM does not support (yet) - I don't want to add support for it.

There is no need to do so: one can write a post-install+post-update hook which will copy (on *nix and not very old windows: only post-install, symlink) some files to plugin_root_dir/new_rtp and make VAM think that new_rtp is a plugin runtimepath: similar solution to what I suggested for plugins without normal directory structure in git repository. Not implemented because no one of VAM-kr committers are enough convinced at this point.

This solution requires maintainer that will look for changed number of files devoted to each of the plugins.

[MarcWeber]

Excerpts from ZyX-I's message of Sun Feb 26 17:25:05 +0100 2012:

This solution requires maintainer that will look for changed number of files devoted to each of the plugins. Seriously: Its easier to ask the author to split it into two git repositories. Its not us fixing the world IMHO. Let's not over engineer unless necessary or requested by users.

Marc Weber

[gotgenes]

I agree with Marc; this seems much easier to solve socially than technically. In my case, I have already asked sjbach to consider splitting up the lusty repository. I am optimistic plugin maintainers will be happy to adapt to these plugin management systems because they increase overall adoption rate.

[ZyX-I]

Let's not over engineer unless necessary or requested by users.

I did not say I want to/will do so. But it the way things may be done with the current set of features.