Package CedarBackup2 :: Module util :: Class PathResolverSingleton
[hide private]
[frames] | no frames]

Class PathResolverSingleton

source code

object --+
         |
        PathResolverSingleton

Singleton used for resolving executable paths.

Various functions throughout Cedar Backup (including extensions) need a way to resolve the path of executables that they use. For instance, the image functionality needs to find the mkisofs executable, and the Subversion extension needs to find the svnlook executable. Cedar Backup's original behavior was to assume that the simple name ("svnlook" or whatever) was available on the caller's $PATH, and to fail otherwise. However, this turns out to be less than ideal, since for instance the root user might not always have executables like svnlook in its path.

One solution is to specify a path (either via an absolute path or some sort of path insertion or path appending mechanism) that would apply to the executeCommand() function. This is not difficult to implement, but it seem like kind of a "big hammer" solution. Besides that, it might also represent a security flaw (for instance, I prefer not to mess with root's $PATH on the application level if I don't have to).

The alternative is to set up some sort of configuration for the path to certain executables, i.e. "find svnlook in /usr/local/bin/svnlook" or whatever. This PathResolverSingleton aims to provide a good solution to the mapping problem. Callers of all sorts (extensions or not) can get an instance of the singleton. Then, they call the lookup method to try and resolve the executable they are looking for. Through the lookup method, the caller can also specify a default to use if a mapping is not found. This way, with no real effort on the part of the caller, behavior can neatly degrade to something equivalent to the current behavior if there is no special mapping or if the singleton was never initialized in the first place.

Even better, extensions automagically get access to the same resolver functionality, and they don't even need to understand how the mapping happens. All extension authors need to do is document what executables their code requires, and the standard resolver configuration section will meet their needs.

The class should be initialized once through the constructor somewhere in the main routine. Then, the main routine should call the fill method to fill in the resolver's internal structures. Everyone else who needs to resolve a path will get an instance of the class using getInstance and will then just call the lookup method.

Nested Classes [hide private]
  _Helper
Helper class to provide a singleton factory method.
Instance Methods [hide private]
 
__init__(self)
Singleton constructor, which just creates the singleton instance.
source code
 
lookup(self, name, default=None)
Looks up name and returns the resolved path associated with the name.
source code
 
fill(self, mapping)
Fills in the singleton's internal mapping from name to resource.
source code

Inherited from object: __delattr__, __format__, __getattribute__, __hash__, __new__, __reduce__, __reduce_ex__, __repr__, __setattr__, __sizeof__, __str__, __subclasshook__

Class Variables [hide private]
  _instance = None
Holds a reference to the singleton
  getInstance = <CedarBackup2.util._Helper object>
Instance Variables [hide private]
  _mapping
Internal mapping from resource name to path.
Properties [hide private]

Inherited from object: __class__

Method Details [hide private]

__init__(self)
(Constructor)

source code 

Singleton constructor, which just creates the singleton instance.

Overrides: object.__init__

lookup(self, name, default=None)

source code 

Looks up name and returns the resolved path associated with the name.

Parameters:
  • name - Name of the path resource to resolve.
  • default - Default to return if resource cannot be resolved.
Returns:
Resolved path associated with name, or default if name can't be resolved.

fill(self, mapping)

source code 

Fills in the singleton's internal mapping from name to resource.

Parameters:
  • mapping (Dictionary mapping name to path, both as strings.) - Mapping from resource name to path.