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.
You can download a public release containing the source from: http://sourceforge.net/project/showfiles.php?group_id=116235
. 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
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 -d:pserver:firstname.lastname@example.org:/cvsroot/pyfmf login
When prompted for a password for anonymous
, simply press the Enter
Then check out the files:
cvs -z3 -d:pserver:email@example.com:/cvsroot/pyfmf 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 http://www.python.org
You can just browse the code from http://cvs.sourceforge.net/viewcvs.py/pyfmf/danperl/zigzag.
See "Basic Introduction to CVS and SourceForge.net (SF.net) Project CVS Services
" for more general info on using CVS with SourceForge.net.
The main script is src/ctrlr/zigo.py
. Import it into your own application or run it by itself. The usage for running the script by itself is:
python zigo.py <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>
python zigo.py ctrlrCfg
python zigo.py frsCfg config/saved/frsCfg.zip
Notice that the argument for the configuration module doesn't need the '.py
' at the end, although it corresponds to a ctrlrCfg.py
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 ctrlr.py
as an example of how to use the framework.
Configuration in zigo
is through manual coding and is much more complex than configuration in zago
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 ctrlr.py
script. This dictionary has four members, with the keys 'topDirs'
. There are two examples of configuration modules that define a configDict
. Both are exactly the same configuration, but ctrlrCfg.py
imports other modules and builds configDict
in steps, whereas exampleCfg.py
has a flat, explicit, definition of configDict
. [Note: you have to modify the ctrlrCfg.py
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
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
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'
, and 'typ'
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'
, or 'sequence'
). A 'sequence'
value can be either a tuple or a list of strings.