-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Comments
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..) 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! |
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 |
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. |
@leifwickland, see #54 |
Shiny; that worked. Thanks, @gmarik. |
I've been struggling with dependencies, too. For instance FuzzyFinder requires L9, and L9 requires vim 7.2+. For now I've got:
and
While this prevents "errors" on launch, BundleInstall won't install FuzzyFinder until it's run for the 2nd time. |
Why not just put the |
hah yeah I just thought of that, too, but that only works for this trivial case... |
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. |
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. |
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. |
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?
At least it lets you have less conditionals ) |
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. |
+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. |
+1 #384 goes against. |
What about using the vim-pi repository for the dependencies? |
What about a The file could contain |
I think spec file(JSON?) is better instead of depends.vim.
The plugin managers does not have to recognize Vim script. |
Spec files may be better, but they seem a little too complicated for just dependencies.
So how about a text file containing just plugin names? That would be very KISS. |
Yes. I think the file should provide other information.
It is simple. But plugin managers must parse it. I think more standard file format is better. |
ping |
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?The text was updated successfully, but these errors were encountered: