Project:Portage/Repoman-Module-specs

Repoman has three plugin module systems:


 * vcs: various vcs specific code modules, eg: git, hg (mercurial), svn (subversion), ...
 * scan: Holds the primary checks performed by repoman
 * linechecks: An ebuild module submodule plugin system for performing the checks in the multi-check operations of the ebuild module. These checks are run on the various lines of the ebuild itself.  Looking for common errors, invalid data, etc...

Common Module specs

 * 1) Each module is contained in a directory of the same name and should reflect the type of module operations it performs.
 * 2) The directory requires and __init__.py.  This file contains specifics about the module classes it provides and the info required by those classes.
 * 3) The module can contain an arbitrary amount of files to perform the tasks.  However, the details of the exported classes must be listed in the module_spec dictionary in the __init__.py.  It is only this file and data which is imported and loaded upon startup.  The classes and functions the module defines are only imported and initialized when needed.
 * 4) Each module should not require information from another module, nor import code from any other module.  They should be self contained other than getting information from the parent process.

VCS Modules
The vcs module is required to supply two classes: * A status class, various functions or methods to supply status information repoman requires. * A changes class, a method to scan the vcs for changes needing to be committed.

The required exported functions for the status module are: ['check', 'supports_gpg_sign', 'detect_conflicts'] If not relevant to the vcs, then dummy functions must be provided to return correct return values to repoman.

The required exported functions for the changes module are: ['scan']

Scan Modules
A detailed explanation of the above is to be added in future... (TODO)

A scan module should sublclass the above ScanBase class, override the functions as needed. A scan module has up to three options to run code at certain points in the full scan cycle.
 * 1) runInPkgs:  This is for scans to be run at the package level (ie: all ebuilds, metadat.xml, etc.)  List all functions to be run at this point in the cycle.
 * 2) runInEbuilds: This is for scans to be run on a specific ebuild.
 * 3) runInFinal: This is to for primarily for checks to be performed at the end of the scan cycle.  (ie: summarize data from functions in the previous two levels, pass or fail accordingly)

Configuration
The following is the format of the repository level configuration files. The files are stacked according to the layout.conf inheritance order. In this way a repository can inherit another repositories repoman configuration, then extend or limit the actions it will perform on the specific repositrory.