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.
|
_Helper
Helper class to provide a singleton factory method.
|
|
|
|
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__
|
|
_instance = None
Holds a reference to the singleton
|
|
getInstance = <CedarBackup3.util._Helper object>
|
|
_mapping
Internal mapping from resource name to path.
|
Inherited from object :
__class__
|
Singleton constructor, which just creates the singleton instance.
- Overrides:
object.__init__
|
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.
|
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.
|