CedarBackup2.util.PathResolverSingleton

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 = `_Helper()`

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.