Contact: danperl@users.sourceforge.net
Downloads: http://sourceforge.net/project/showfiles.php?group_id=116235
pyfmf: a file management framework in python
Page Changed: 1/19/2005
Zigo
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: 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).
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 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/pyfmf login
When prompted for a password for anonymous, simply press the Enter key. Then check out the files:
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/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.
Use It
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>. Examples:
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.
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 ctrlr.py 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/ctrlrCfg.py, config/exampleCfg.py. 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 and exampleCfg.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 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.
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.
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 ctrlr.py 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/ctrlrCfg.py, config/exampleCfg.py. 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 and exampleCfg.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 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.