Custom file tasks (documented here) have changed substantially in Pyrus. Fortunately, the XML format of tasks used in package.xml remains the same, and Pyrus's expectation of custom task implementation does not conflict or overlap with PEAR's at all, so custom task packages can easily be designed to work with both PEAR and Pyrus.

The biggest difference between how a custom task is implemented in Pyrus has to do with the new plugin system (documented here). Before reading any further, it may be a good idea to familiarize yourself with the way that plugins work in Pyrus by reading the documentation on plugins, then return back to finish reading about custom tasks.

In PEAR, custom tasks are detected simply by scanning the PEAR/Tasks directory, and no differentiation is made between tasks built into PEAR, and external custom tasks.

Pyrus custom tasks are detected through the use a new XML metadata format. The format is simple, and looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<task xmlns="http://pear2.php.net/dtd/customtask-2.0" version="2.0">
 <name>mytask</name>
 <classprefix>vendor_PackageName</classprefix>
 <autoloadpath/>
</task>

The details of what <classprefix> and <autoloadpath> mean are revealed in the full documentation of custom tasks here.

This XML metadata file is identified by Pyrus through the use of the file role customtask, which is used in the custom task's package.xml. Here is an example from the <contents> of a package.xml:

...
  <contents>
   <dir name="data">
    <file name="mytask.xml" role="customtask"/>
    <file name="someotherdata.csv" role="data"/>
   </dir>
  </contents>
...