Artifact 0524ccb5218b1412081a7fd2a0fbd82a2b05ebe2e86a0002251c8b3ee84c98db:

Wiki page [depends] by mario on 2018-07-04 01:27:52.
D 2018-07-04T01:27:52.061
L depends
N text/x-markdown
P 6d331fd288d8cce33fa22feab8311c9bf03249202211c961ff0f129f28e96f2f
U mario
W 1516
## # 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 binaries
  * `python: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:`

Z 74675168a65370fbd160667b01364a44