Declare dependencies about vim-mark HOT 3 CLOSED

Hey Luc,

thanks for the suggestion. I'm still a bit torn about this - I think you've essentially delivered the best argument against this yourself, by mentioning two different ways to declare dependencies. I didn't know VimFlavor so far, I had heard about Vim-Addon-Manager, but I think the most common Vim package managers still are Vundle and vim-plug, and those apparently don't support dependency metadata at all. So as long as there's no agreed-upon standard for declaring dependencies, this looks like a lot of duplicated effort for a small group of beneficiaries each.

For me, about 90% of my plugins have this dependency to the ingo-library plugin, just a few have some more dependencies, and the remaining 9% have no dependencies. Even though I document the dependency prominently in the help file and readme, there always are people who don't read the documentation and don't know enough about Vim (or how to google :-) to realize that the dependency is missing, and then contact me - previously via email, now mostly via GitHub issue. Creating a GitHub issue template that mentions this has basically solved that problem for me.

If I understand vim-py correctly, this includes a database of plugins and their dependencies. I use several old and unmaintained (but still perfectly working!) plugins myself, so the sad truth is that many plugins will never declare their dependencies themselves, even if the Vim community would agree on a single format for them. Having an open database where volunteers supply this information sounds like a good idea, and package managers could then query that database.

I'm a huge admirer of the powerful package managers in Linux distributions (like Debian's apt and Redhat's dnf). The dependencies between Vim plugins are much more benign, though; usually just one or two. With the new Vim 9 syntax, there would be a chance to include dependency management right in core Vim and the new language syntax. However, I haven't seen any proposal about that yet; I suppose Bram sees this as a non-issue, too. So, while my inner perfectionist also desires a clean and formal specification of dependencies, I think right now, with just two aspiring package managers supporting dependencies (and it's really sad that Vim-Addon-Manager does not allow dependencies to a minimal version; that's something really useful for my evolving ingo-library), the informal, human documentation-only approach is actually fine.

from vim-mark.

So as long as there's no agreed-upon standard for declaring dependencies, this looks like a lot of duplicated effort for a small group of beneficiaries each.

Unfortunately we have a vicious circle here. Most authors avoid dependencies because trendy plugin managers don't support them. Hence trendy plugin managers don't need to support dependencies. :(

We are among the few to factorise out functions into libraries. On the subject, in the worst case I have up-to 9 direct and indirect dependencies in lh-cpp ^^'

Having an open database where volunteers supply this information sounds like a good idea, and package managers could then query that database.

That's was vim-pi objective, but unfortunately, VAM was the only plugin to ever use it, and it seems no longer maintained :(

With the new Vim 9 syntax

Indeed. Vim9 is not about dynamic retrieval of plugins, but about clean import of definitions (functions, commands...) from other files. Somehow it's quite similar to Python's approach.

the informal, human documentation-only approach is actually fine.

My issue appeared the moment I've updated Mark as you've introduced the dependency since my previous update.

from vim-mark.

Most authors avoid dependencies because trendy plugin managers don't support them. Hence trendy plugin managers don't need to support dependencies. :(

I don't see it that way, but maybe because I started Vim development when there were no pack plugins and no package managers other than Vimball.

I first duplicated the autoload scripts that contain common functionality into each plugin, but soon realized that the resulting version hell and conflicts are much worse than the extra effort of extracting a shared library. DrChip also packaged his cecutil.vim into many of his plugins; I think it's now also a separate one (and he had also invented the GetLatestVimScripts dependency manager, and uses that to reference it - too bad his plugins haven't yet made the jump to GitHub, or else an adapted GetLatestVimScripts might already be the solution we're all longing for).

Regarding third-party dependencies, I don't see that too often. While there are a couple of common Vimscript libraries, most are only used by the author himself, or maybe some tight-knit group (like the vim-jp folks in Japan). When I reuse other plugins, it's mostly for optional integration, not required.

My issue appeared the moment I've updated Mark as you've introduced the dependency since my previous update.

In the past, you would likely have downloaded the Vimball from vim.org, and seen the major version change (from 2.x to 3.0.0), and read the notes:

3.0.0	18-Sep-2017
- Add dependency to ingo-library (vimscript #4433). *** You need to separately
  install ingo-library (vimscript #4433) version 1.020 (or higher)! ***

But with a plugin manager, all of that was likely hidden from you :-( My point is, as the plugin worked for you in the past, you've likely suspected a dependency change (either newer Vim version or other dependency). Maybe you found :help mark-installation or :help mark-dependencies, or you've gone to the GitHub issues, and either found an existing (closed) issue, or read my note when opening a new one. At least that's what I hope will happen :-) It's a bit of a hassle for the user and a bit of red tape for me (maintaining the docs and GitHub template), but it's not too much and doesn't require any common technology that unfortunately doesn't exist yet.

from vim-mark.