Lists other plugins or language/system libraries which the current plugin expects:
# depends: corefuncs, json_io, bin:bash
Each entry is a plugin basename, and indicates it must be available/active alongside.
The recommended field name is "depends" and not "require" - for parity with the Debian packaging spec, and because it sounds less stringent.
Not every application would want to enforce this strictly. Because dynamic languages can soft-detect dependencies usually.
Within a plugin management UI, the depends: list could be used for installation warnings.
It's optional, and might be treated as documentation in some implementations.
Additionally the plugin names can be suffixed with a version comparison:
# depends: core (>= 2.0.0)
Which obviously does require the plugin manager to be somewhat more involved. You'll often get away just implementing a
>= check. Other version expressions are usually overkill for simple application-level features.
TYPE:name entry can reference other scopes (instead of application-local plugins)
||verify a binary exists|
||for language modules|
||e.g. the architecture.|
||as hint for the system package manager.|
This is quite informal still. There's seldomly practical value to implement such complex dependency lookups, or these exact ones. This is just the advised syntax.
Optionally one could handle a few plain basenames specically For instance checking the current language runtime with:
# depends: python (>= 3.4)
Or, if feasible, even module versions
# depends: php:sqlite (>= 3.24)
Depending on complexity other fields might be used alongside:
Does occasionally make sense for variants or mutally exclusive features. Though could be implemented as
# depends: !feature or
feature (< 0.0) with version expression support.
Defines a virtual feature identifier to be present. Less commonly needed for application plugins.
A weak recommendation of other plugins to go along with. Should foremost be handled in the admin UI or a plugin download interface.