I want to suggest a different way of handling constants.py and config.py
the current way is clumsy and makes making convoluted code easy.

GLOBAL VARIABLES ARE BAD. It's not something I invented. It's well 
accepted that proper scoping yields better code.

The way we use those two files shows how much of a mess globally 
accessible variable can be.

Not putting paths to executable in constants.py
Instead we should have a module for each utility executable. The module 
should wrap the utility with a pythonic interface. That way there is no 
reason for more then one module to have access to a utility's path.

For example:



def cat(files):
    cmd = [_CAT_PATH] + files
    out, err = exec(cmd)
    return out

Now there is no need to know where cat is. You have a proper interface 
to use. Preventing people from re-wrapping the utility over and over. 
This in turn means you have a canonical wrapper that is more likely to work.

Every other constant
Other constants should be moved to their proper modules and used only 
when importing the module makes sense this will give you another step 
where you make sure your decencies are correct.


Configuration files are just parameters to the program. They should be 
treated as such. Their scope should not leave the main class of the 
project. In our case VDSM is actually 2 projects meshed together like 
Siamese twins so I think clientIf.py and hsm.py should be the only ones 
with access to the config. Everything else should expect to get those 
values in a regular programmatic fashion.

In my opinion these changes will make VDSM a lot more flexible, will 
make more parts independent and easily separated and at that end help us 
make VDSM better for generations to come.

You can help!

* Start by taking you favorite utility and write a proper safe module 
around it.
* When writing new code try and not access the configuration directly.
* Modules are free (really) don't just put stuff in misc\utils try and 
put some order to things.

vdsm-devel mailing list

Reply via email to