| Artifact ID: | c14a4b47029651663180bf1ffd99e3d8eb4faf19bcdc06c4c1fe13efe3cbb6ee |
|---|---|
| Page Name: | depends |
| Date: | 2018-07-04 13:32:42 |
| Original User: | mario |
| Mimetype: | text/x-markdown |
| Parent: | fd8ff09ebad1fdf5f2782cc7480a041c1ad2e738c2cb2f58cbc3707ec4341ebf (diff) |
| Next | 7690f09f7fb8b48ee45fcb282a6e094c82df8becad1d010c6788486ae3248983 |
# 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 ] |
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: