Class 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.
Method Summary |
|
__init__ (self)
Singleton constructor, which just creates the singleton instance. |
|
fill (self,
mapping)
Fills in the singleton's internal mapping from name to resource. |
|
lookup (self,
name,
default)
Looks up name and returns the resolved path associated with the
name. |
Class Variable Summary |
_Helper |
getInstance = <CedarBackup2.util._Helper instance at 0x4...
|
__init__(self)
(Constructor)
Singleton constructor, which just creates the singleton
instance.
-
|
fill(self,
mapping)
Fills in the singleton's internal mapping from name to resource.
-
- Parameters:
mapping -
Mapping from resource name to path.
(type=Dictionary mapping name to path, both as strings.)
|
lookup(self,
name,
default=None)
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.
|
getInstance
-
- Type:
-
_Helper
- Value:
<CedarBackup2.util._Helper instance at 0x40295f0c>
|
|