History Page Raw
Overview

Artifact ID: 4ff727a3adde1f4d9068678e1c4541626ab425a9d29b49c5bdb2f62a50f762da
Page Name:depends
Date: 2018-07-04 01:42:26
Original User: mario
Mimetype:text/x-markdown
Parent: 0524ccb5218b1412081a7fd2a0fbd82a2b05ebe2e86a0002251c8b3ee84c98db (diff)
Next fd8ff09ebad1fdf5f2782cc7480a041c1ad2e738c2cb2f58cbc3707ec4341ebf
Content

# 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 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 it strictly. It can be 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: