Vundle.vim: Support plugin dependencies

[intuited]

I've been using vim-addon-manager, which does more or less what this addon seems to do. I've not used vundle yet, so I'm not sure how similar the two addons are, but VAM does provide the same core functionality of allowing addons to be installed and enabled from within vim itself. VAM is a bit sprawling, partly because it also does the work of vim-scripts.org itself, allowing addons to be pulled in directly from vim.org or from git, SVN, hg, etc. repos. So it's nice to see this more concise addon being made available as a potential replacement.

One thing that VAM provides that I don't see in vundle is the ability to declare addon dependencies. Each addon can have a file called ${ADDON_NAME}-addon-info.txt in the root of its directory structure. This text file is in vim-compatible JSON format and allows various metadata, including dependencies on other addons, to be declared. To me, this is a must-have feature, since it provides a way to modularize complex VimL code into libraries, allowing more complex functionality to be shared among addons and reducing code duplication and memory footprints.

Is there a possibility that this feature might be worked into vundle? If so, could a compatible metadata format be used?

[gmarik]

Hey intuited!

Short answer: dependencies are on TODO list.

I can't name plugins with complex dependency graphs, that's why it's a low priority to _me_. And you're the only one who have mentioned it so far..)
The idea of sharing code and creating reusable libraries is great!
Whole community will benefit of it.

JSON is ok to me. And yes, Vundle could reuse VAM's metadata file to manage dependencies.

Right now i'm working on other features though. I should probably update TODO list and create a discussion group to get more feedback!

Thanks for your one!

[intuited]

Okay, well I'm happy to learn that it should be on the list.

One example of an addon that does use dependencies is jsonvim. It actually uses quite a few. Unfortunately, they are published in HG repos, which wouldn't work without mercurial support.

That addon, I gather, will parse JSON more securely than by using a VimL eval() call. The docs mention that it calls out to Python if possible, for speed and support of surrogate pairs. Parsing via Python is I think faster than using vim eval().

[leifwickland]

https://github.com/MarcWeber/ensime is another plugin with a complicated dependency graph.

(Separately) A problem I've encountered using ensime with Vundle is that ensime has a vim directory containing the normal stuff as a subdirectory of the root. I was able to trick pathogen into using the vim directory by creating a symlink to the ensime/vim dir in my .vim/bundle directory, but Vundle doesn't fall for that trick.

[gmarik]

@leifwickland, see #54
basicly you need
Bundle 'MarcWeber/ensime', {'rtp': 'vim/'}

[leifwickland]

Shiny; that worked. Thanks, @gmarik.

[apinstein]

I've been struggling with dependencies, too. For instance FuzzyFinder requires L9, and L9 requires vim 7.2+.

For now I've got:

if v:version >= 702
    Bundle 'L9'
endif

and

if exists("*l9#getVersion")
    Bundle 'FuzzyFinder'
endif

While this prevents "errors" on launch, BundleInstall won't install FuzzyFinder until it's run for the 2nd time.

[randymorris]

Why not just put the Bundle 'FuzzyFinder' directly below the Bundle 'L9' line?

[apinstein]

hah yeah I just thought of that, too, but that only works for this trivial case...

[randymorris]

I'm not sure my opinion means much here, but I really don't think the added complexity of dependency tracking is really necessary in vundle. If a large set of plugins were using common libraries (a pipe dream I will not live to see) then it would be more important. However, there are so few plugins that have complex dependencies that I feel this is better left up to the user.

[apinstein]

The reason it's important to me is that I have a dotfiles script that runs on heterogenous environments. I use a simple rake script that I can run on every machine to bootstrap _everything_. In one pass it will install vundle and bootstrap all of my vundle plugins. Dep mgmt would have made it a little easier for me to get that working. Instead of having to use custom vim script to detect and conditionally Bundle XXX things, it would've been slightly easier.

Now just b/c it's important to me doesn't mean it's worth doing; I'm just sharing.

[intuited]

In reference to rson's comment: I think the biggest reason that there are not large sets of plugins using common libraries is because there is no predominant package manager that provides dependency management. Maybe most users are happy with the ecosystem as it is, but in my experience, development of somewhat complex plugins has involved reinventing a lot of wheels that are already out there. I feel that dependable dependency management [sic] would help to resolve this problem. For instance, the vimclojure plugin can be used to interact with a running clojure instance from within vim. I split it into two modules and generalized the "core" one so that I can also use it with a third module I wrote to enable interaction with nodejs. However, without dependency management, there's no way to properly publish my work.

[gmarik]

It's on TODO, and as @rson mention the complexity vs utility make it not the highest priority ATM.

As possible solution to @apinstein's problem,

Did you try having separate bundle lists per environment?
Then in vimrc you could just do smth like:

 set rtp+=~/.vim/bundle/vundle/
 call vundle#rc()

if v:version < 702
 source bundles-old.vim
else 
 source bundles-modern.vim
endif
" ..

At least it lets you have less conditionals )

[stephenmm]

Sorry to be tagging on to this so late but I completely agree with intuited and especially with his last comment (perfect example). Its definitely a chicken and egg thing. So bump from me as well.

[chiphogg]

+1 for dependency support. @intuited has it right -- people don't use dependencies because popular plugin managers don't support them.

The pathogen/vundle model was a watershed event for vim plugins. Dependency handling is the next big leap.

[cirosantilli]

+1 https://github.com/gmarik/Vundle.vim/issues/384 goes against.

[RedX2501]

What about using the vim-pi repository for the dependencies?

[ghost]

What about a depends.vim file in the root of the plugin directory?

The file could contain Plugin 'name' lines for each dependency.
Then it would be a simple matter of having Vundle source that file (if it exists) for each plugin!

[Shougo]

I think spec file(JSON?) is better instead of depends.vim.

What about a depends.vim file in the root of the plugin directory?

The plugin managers does not have to recognize Vim script.

[ghost]

I think spec file(JSON?) is better instead of depends.vim.

Spec files may be better, but they seem a little too complicated for just dependencies.

The plugin managers does not have to recognize Vim script.

So how about a text file containing just plugin names? That would be very KISS.
Alternatively, how about Debian style Depends:, Recommends:, Suggests: lines?

[Shougo]

Spec files may be better, but they seem a little too complicated for just dependencies.

Yes. I think the file should provide other information.

So how about a text file containing just plugin names? That would be very KISS.
Alternatively, how about Debian style Depends:, Recommends:, Suggests: lines?

It is simple. But plugin managers must parse it. I think more standard file format is better.

[kuraga]

ping