Skip to content
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

Support plugin dependencies #7

Open
intuited opened this issue Mar 17, 2011 · 21 comments
Open

Support plugin dependencies #7

intuited opened this issue Mar 17, 2011 · 21 comments
Labels
Milestone

Comments

@intuited
Copy link

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
Copy link
Contributor

gmarik commented Mar 18, 2011

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
Copy link
Author

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
Copy link

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
Copy link
Contributor

gmarik commented Jun 6, 2011

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

@leifwickland
Copy link

Shiny; that worked. Thanks, @gmarik.

@apinstein
Copy link

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
Copy link
Contributor

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

@apinstein
Copy link

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

@randymorris
Copy link
Contributor

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
Copy link

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
Copy link
Author

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
Copy link
Contributor

gmarik commented Nov 22, 2011

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
Copy link

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
Copy link
Contributor

+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
Copy link

+1 #384 goes against.

@RedX2501
Copy link

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

@ghost
Copy link

ghost commented Feb 13, 2015

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
Copy link
Contributor

Shougo commented Feb 15, 2015

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
Copy link

ghost commented Feb 16, 2015

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
Copy link
Contributor

Shougo commented Feb 16, 2015

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.

@ghost ghost mentioned this issue Feb 17, 2015
@jdevera jdevera changed the title Dependencies? Support plugin dependencies Feb 17, 2015
@kuraga
Copy link

kuraga commented Nov 18, 2016

ping

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.