Config Mode Definitions and Enable Mode Definitions for platforms that don't support one or both of these.

[ktbyers]

Netmiko has the following six methods.

    def check_enable_mode(self, check_string: str = "") -> bool:
        ...

    def enable(
        self, cmd: str = "", pattern: str = "ssword", re_flags: int = re.IGNORECASE
    ) -> str: 
        ... 

    def exit_enable_mode(self, exit_command: str = "") -> str: 
        ...

    def check_config_mode(self, check_string: str = "", pattern: str = "") -> bool:
        ... 

    def config_mode(
        self, config_command: str = "", pattern: str = "", re_flags: int = 0
    ) -> str: 
        ...

    def exit_config_mode(self, exit_config: str = "", pattern: str = "") -> str: 
        ...

If enable mode does not exist on a device, then the driver should do the following:

1. check_enable_mode should always return True (with minor caveat below)
2. Both enable and exit_enable_mode should return a null string.

Reasoning: Being in enable mode from Netmiko's perspective means that you have the capability of making configuration changes (or more exactly, for cisco-ios like devices that you can execute config term). You are not in configuration mode, per se, but you can execute the commands to do this (if required). Or alternatively, you can directly execute configuration commands for platforms that do not have a separate configure mode.

If the device has no capability of executing configuration changes from the CLI, then check_enable_mode should always return False and enable() call should raise an exception. This driver would inherently be limited only to show command operations.

If config mode does not exist on a device, then the driver should do the following:

1. check_config_mode should always return True (with caveats below).
2. Both config_mode and exit_config_mode should always return a null string.

Reasoning: Being in config mode implies that configuration changes can be made on a device. So most platforms that do not have a configuration mode, allow you to directly make configuration changes. In other words, you don't need to execute config term or something similar to make configuration changes, you can just make your configuration changes (consequently, check_config_mode should return True in these cases).

If the device does not actually allow any configuration changes to be made, then you should always return False. Additionally, in these cases config_mode should return an exception.

Type hints for these methods.

In general, you should always specify all of the arguments in the method signature for these six methods as they are unlikely to change and it helps with IDEs. Additionally, you should pass ALL of the arguments to any super() invocations so that if end-users actually pass-in the arguments, they work properly.

It is probable that I will create some sort of a mix-in that contains the proper code for all the drivers that fall into this category (to avoid all of the duplicate definitions of this code).

[wrgeorge1983]

Clear guidance on this is great!

Mixin also sounds great, the only reason it might be worth avoiding is because it might raise the barrier of entry a bit for new contributors. "Go learn about multiple inheritance" might be a bit much for new networker-turned-automators in the future.

Though maybe that's over thinking it. In a use-case like this it's not so bad. Documentation can still be straightforward:

If config or enable modes do not exist on a device

Inherit from NoConfigMixin and\or NoEnableMixin as appropriate:

class MyDevice(NoConfigMixin, NoEnableMixin, CiscoBaseConnection):
  pass

[wrgeorge1983]

@ktbyers

this kind of match the intent you described?

class NoConfigMixin:
    """Mixin class for devices with no 'config' mode (because they allow config changes by default)"""
    def check_config_mode(self, check_string: str = "", pattern: str = "") -> bool:
        return True

    def config_mode(
        self, config_command: str = "", pattern: str = "", re_flags: int = 0
    ) -> str:
        return ""

    def exit_config_mode(self, exit_config: str = "", pattern: str = "") -> str:
        return ""


class NoEnableMixin:
    """Mixin class for devices with no 'enable' mode (because they allow privileged access by default)"""
    def check_enable_mode(self, check_string: str = "") -> bool:
        return True

    def enable(
        self, cmd: str = "", pattern: str = "ssword", re_flags: int = re.IGNORECASE
    ) -> str:
        return ""

    def exit_enable_mode(self, exit_command: str = "") -> str:
        return ""


class NoChangesMixin:
    """Mixin class for devices that cannot apply any config changes via CLI.
    Indicates `False` for enable and config mode checks, and raises NotImplementedError if you attempt to enter those
    modes."""
    def check_enable_mode(self, check_string: str = "") -> bool:
        return False

    def enable(
        self, cmd: str = "", pattern: str = "ssword", re_flags: int = re.IGNORECASE
    ) -> str:
        raise NotImplementedError

    def exit_enable_mode(self, exit_command: str = "") -> str:
        return ""

[ktbyers]

Yeah, that is pretty much what I was thinking.

I probably am okay with the raising the barrier to entry for new contributors as:

1. It is a lot of work to maintain these child classes (for example retrofitting them for type hints).
2. There ends up being a lot of drift (too much) on what gets implemented so having it one place for the "no config" and/or "no enable" would be very helpful.