D 2018-07-04T13:27:27.817
L depends
N text/x-markdown
P 4ff727a3adde1f4d9068678e1c4541626ab425a9d29b49c5bdb2f62a50f762da
U mario
W 1735
## # 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. 


## 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.


## 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 `>=` check of course. Most other version expression gimmicks are usually overkill for simple applicatiion-level features.


## Related fields

Depending on complexity other fields might be used alongside:

  * `# provides:`
  * `# conflicts:`
  * `# suggests:`

Z 27c437605dfc860546399783c6a2c5f0