D 2018-07-04T13:32:42.293
L depends
N text/x-markdown
P fd8ff09ebad1fdf5f2782cc7480a041c1ad2e738c2cb2f58cbc3707ec4341ebf
U mario
W 1726
## # depends:
Lists other plugins or language/system libraries which the current plugin requires:
# depends: corefuncs, json_io, bin:bash
Typically it just lists other plugin basenames. To indicate which must be available/active alongside.
* It's a list of local URNs.
* The recommended field name is "depends" and not "require" - for compatibility 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.
## Versioned dependencies
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. Most other version expression gimmicks are likely overkill for simple applicatiion-level features.
## System/language dependencies
While a `TYPE:name` entry can reference other scopes (instead of application-local plugins)
| `bin:imagemagick` | for binaries |
| `python:lxml` | for language modules |
| `sys:amd64` | for the architecture. |
| `deb:anacron` | as hint for the system package manager. |
| `api:archnemesis` | see [api](wiki/api) ]
This is quite informal still. There's also less practical value to implement theese complex dependency lookups, or these exact ones. This is just the advised syntax.
## Related fields
Depending on complexity other fields might be used alongside:
* `# provides:`
* `# conflicts:`
* `# suggests:`
Z 5a2c4456561025062d2eb42003ae0fe3