Pyrus defines three kinds of plugins: commands, file roles, and file tasks. Commands add new commands to a frontend for Pyrus, file roles and file tasks add new features to package.xml.

Pyrus, by necessity, requires a clear separation between its plugins and its core. This is because Pyrus is distributed as a phar archive, which cannot be modified without jumping through several hoops. For this reason, plugins are installed in a special directory whose location is specified by the plugins_dir user configuration variable.

Pyrus also makes a clear separation between regular packages and plugin packages. Plugins must be installed separate from any non-plugin packages using the --plugin option of the install, upgrade, and uninstall command. Here is an example, installing the developer tools plugin:

php pyrus.phar install -p PEAR2_Pyrus_Developer

Pyrus defines a plugin as any package that contains one of the three file roles that identify a plugin: customcommand, customrole, or customtask. In addition, a plugin package can only contain one plugin. This helps users by mapping one package to one plugin so that when they list plugin packages, it clearly shows all of the plugins that are installed.

A plugin's definition is handled by an XML file, which must be referenced using one of the three plugin file roles in package.xml. Here is an example identifying a custom command in package.xml:

...
  <dir name="/">
   <dir name="customcommand" baseinstalldir="/">
    <file role="customcommand" name="commands.xml"/>
   </dir>
...
Pyrus Custom File Tasks: differences from PEAR (Previous) Telling Pyrus how to load your plugin: <class> and <autoloadpath> (Next)
Last updated: Sun, 20 Apr 2014 — Download Documentation
Do you think that something on this page is wrong? Please file a bug report or add a note.
View this page in:

User Notes:

There are no user contributed notes for this page.