D 2018-07-05T18:33:49.922
L depends
N text/x-markdown
P 3c6f35255c8a2590b3412a0bb4434dd235465b639603b74267d04ef8eec33a13
U mario
W 2450
## # depends:

Lists other plugins or language/system libraries which the current plugin expects:

    # depends: corefuncs, json_io, bin:bash

Each entry is a plugin [basename](wiki/internal-fields#id), 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.


### 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. Other version expressions are usually overkill for simple application-level features.


### System/language references

While a `TYPE:name` entry can reference other scopes (instead of application-local plugins)

| `bin:imagemagick` | verify a binary exists |
| `python:lxml` | for language modules |
| `sys:amd64` | e.g. the architecture. |
| `deb:anacron` | as hint for the system package manager. |
| `api:archnemesis` | see [api](wiki/api) |

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.

### Magic basenames

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)

### Related fields

Depending on complexity other fields might be used alongside:

#### # conflicts:

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.

#### # provides:

Defines a virtual feature identifier to be present. Less commonly needed for application plugins.

#### # suggests:

A weak recommendation of other plugins to go along with. Should foremost be handled in the admin UI or a plugin download interface.

Z edefdd9cfffab1292137779602738e9a