Structure of the "Imager" for code reusability

[operatorequals]

As the imager will use os functions like os.listdir() and os.path.isdir(), it is best to create an abstraction layer of those functions (directory listing, checking if directory, etc).

That means that a general directory listing function should be used and have different implementation depending on what is listed (the running OS, a remote OS, SatoriImage object, etc).

Example:

[...]
context.listdir()
[...]

can have different meanings as of standard duck-typing as context can be anything (not only os module):

For running system OS with os module:

import os as context
context.listdir()

For Paramiko's SFTP:

context = paramiko.sftp_client.SFTPClient(ssh_sock_obj)
context.listdir()

Extending for SatoriCore objects:

# In SatoriCore
class SatoriImage(object):
    [...]
    def listdir(self, *args, **kwargs):
        [...]

# Usage:
image = SatoriImage()
context = image
context.listdir()

And wrappers can be created for objects that do not have the listdir interface (e.g: SMBHandler of pysmb )

Wrapping the listPath() of pysmb's SMBConnection:

# Abstract Class
from abc import ABC

# In SatoriCore
class SatoriAccessWrapper(ABC):

    @abstractmethod
    def listdir(self): pass     # MUST be implemented in subclass

class SatoriSMBWrapper(SatoriAccessWrapper):
    def __init__(self, smbcon):
        self.smbcon = smbcon    # SMBConnection object
        [...]

    def listdir(self, dir_path):
        dir_list = self.smbcon.listPath('C$', '.')    # accessing the real SMBConnection object
        return dir_list


# Usage:

context = SatoriSMBWrapper(smbcon)
context.listdir()

This way, what can be queried during an Imaging process will be easily controlled.

Additionally, this design will ensure extendability, as any new way to query a FileSystem will have to be wrapped through the SatoriAccessWrapper wrapper class. The Imager will just plug-n-play with those objects.

That's what Java calls interfaces.