Artifact ID: | 0524ccb5218b1412081a7fd2a0fbd82a2b05ebe2e86a0002251c8b3ee84c98db |
---|---|
Page Name: | depends |
Date: | 2018-07-04 01:27:52 |
Original User: | mario |
Mimetype: | text/x-markdown |
Parent: | 6d331fd288d8cce33fa22feab8311c9bf03249202211c961ff0f129f28e96f2f (diff) |
Next | 4ff727a3adde1f4d9068678e1c4541626ab425a9d29b49c5bdb2f62a50f762da |
# 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. And it's a strong indicator that those must be enabled alongside or prior.
It's a list of local URNs.
The recommended default is "depends" and not "require", for compatibility with the Debian packaging spec.
Also it does not strictly need to enforced strictly in each application. It's more of a recommendation and user-visible field. In dynamic langauges plugins can soft-detect missing dependencies mostly.
System/language dependencies
This is quite informal / not fixated, but non-plugin dependencies might also be listed with type:name
like:
bin:imagemagick
for binariespython:lyxml
for language modules- Or
sys:amd64
for the architecture. - And
deb:anacron
for the system package manager. api:archnemesis
etc.
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: