Overview

Artifact ID: 9488f5fbcb4a491dcd23da11af0a90ff27fe66ff791218b1637459d7e81b00ac
Page Name:depends
Date: 2018-07-04 15:44:44
Original User: mario
Mimetype:text/x-markdown
Parent: 4e6fd14579f5ee2859be2dcf92f9c933d3bdf3cd1055bfc7b47214b1db15cc54 (diff)
Next 90ac1bd3eb4d64313d434e9278a40109e99d33bf4aad4083b119358124d8084d
Content

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

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.

Related fields

Depending on complexity other fields might be used alongside:

  • # provides:
  • # conflicts:
  • # suggests: