Logo Home of

pyfmf: a file management framework in python
Page Changed: 1/19/2005


Zigo is a console based toolkit based on the pyfmf framework.  It is an extension of the framework in the sense that it includes also a set of handlers derived from the handler base class (which is part of the framework).  See the "Handlers" page for a list of the existent handlers.

Download It

You can download a public release containing the source from:  Please also note that zigo is included in zago, the graphical platform based on the pyfmf framework.  If you download zago, you do not need to download also a release of zigo (the difference between the two releases is that zago also contains a directory gui).

If you enjoy living dangerously and you want the latest (even if it's un-stable and un-documented) source, you can use CVS to download the files.  Fortunately, that's easy.  First, log in:
cvs login
When prompted for a password for anonymous, simply press the Enter key.  Then check out the files:
cvs -z3 co zigo

There, you have the source files now.  And good thing with Python, that's all you need (assuming that you already have Python installed, otherwise, see

You can just browse the code from  See "Basic Introduction to CVS and ( Project CVS Services" for more general info on using CVS with

Use It

The main script is src/ctrlr/   Import it into your own application or run it by itself.  The usage for running the script by itself is:
    python <config module name> [<path to config package>]
where <config module name> is a module in a config package (directory config under the installation directory).  The config package is expected to be right under the top directory (normally pyfmf).  For a config package under a different path (for instance, if you want to save configurations; this path can also be a zip file), use the optional argument, <path to config package>.  Examples:
    python ctrlrCfg
    python frsCfg config/saved/

Notice that the argument for the configuration module doesn't need the '.py' at the end, although it corresponds to a file.  That's because that argument is not really the file name but the python module name.

If you want to use the framework in your own application, see the code in as an example of how to use the framework.

Configure It

Configuration in zigo is through manual coding and is much more complex than configuration in zago.  You will have to do some exploring in order to figure out all the elements that are configured, but I will try to explain them as well as I can in a few paragraphs.

The configuration is entirely contained in a dictionary, configDict, defined in the module that is passed as an argument to the script.  This dictionary has four members, with the keys 'topDirs', 'workDir', 'handlersCfg' and 'description'.  There are two examples of configuration modules that define a configDict for zigo: config/, config/  Both are exactly the same configuration, but imports other modules and builds configDict in steps, whereas has a flat, explicit, definition of configDict.  [Note: you have to modify the and files in order to use them.  They are only examples and they contain elements that are system specific.  You can also create a separate configuration file, but it has to be part of a config package.  See also the usage section.]

The value associated with 'topDirs' is a list of the roots of directory trees that are to be traversed and processed.  The value associated with 'workDir' is the directory where all result files are located.  The value associated with 'description' is important only for zago and can be left empty if you are using only zigo

The value associated with 'handlersCfg' is a list of tuples.  Each one of the tuples in this list is associated with a handler in the stack.  The order of the list follows the order of the stack, top-to-bottom, the first element in the list corresponding to the top of the stack and the last element of the list corresponding to the bottom of the stack.  Processing is done in reverse order, the bottom handler is the first one to process directories and files, the top handler is the last one processing.

Each tuple in the list associated with 'handlersCfg' has 2 items.  The first item is the name of the module which contains the Handler.  The second item is a dictionary used to configure the Handler instance.  To understand what members are expected in the dictionary for each Handler class, look at the unbound member _metaCfg of that class; it is a tuple of metaCfgCls (a class nested in class baseClass.Handler) objects, each object describing a member of the dictionary.  These objects have three attributes: 'label', 'desc', and 'typ''label' represents the key used in the configuration dictionary, 'desc' represents the description of the configuration entry, and'typ' represents the type of the value ('string', 'bool', or 'sequence').  A 'sequence' value can be either a tuple or a list of strings.