|
4 | 4 |
|
5 | 5 | Cmd2 also enables developers to modularize their command definitions into |
6 | 6 | [CommandSet][cmd2.CommandSet] objects. CommandSets represent a logical grouping of commands within a |
7 | | -`cmd2` application. By default, all `CommandSet` objects will be discovered and loaded automatically |
8 | | -when the [cmd2.Cmd][] class is instantiated with this mixin. This also enables the developer to |
9 | | -dynamically add/remove commands from the cmd2 application. This could be useful for loadable plugins |
10 | | -that add additional capabilities. Additionally, it allows for object-oriented encapsulation and |
11 | | -garbage collection of state that is specific to a CommandSet. |
| 7 | +`cmd2` application. By default, `CommandSet` objects need to be manually registered. However, it is |
| 8 | +possible for all `CommandSet` objects to be discovered and loaded automatically when the |
| 9 | +[cmd2.Cmd][] class is instantiated with this mixin by setting `auto_load_commands=True`. This also |
| 10 | +enables the developer to dynamically add/remove commands from the `cmd2` application. This could be |
| 11 | +useful for loadable plugins that add additional capabilities. Additionally, it allows for |
| 12 | +object-oriented encapsulation and garbage collection of state that is specific to a CommandSet. |
12 | 13 |
|
13 | 14 | ### Features |
14 | 15 |
|
15 | 16 | - Modular Command Sets - Commands can be broken into separate modules rather than in one god class |
16 | 17 | holding all commands. |
17 | 18 | - Automatic Command Discovery - In your application, merely defining and importing a CommandSet is |
18 | | - sufficient for `cmd2` to discover and load your command. No manual registration is necessary. |
| 19 | + sufficient for `cmd2` to discover and load your command if you set `auto_load_commands=True`. No |
| 20 | + manual registration is necessary. |
19 | 21 | - Dynamically Loadable/Unloadable Commands - Command functions and CommandSets can both be loaded |
20 | 22 | and unloaded dynamically during application execution. This can enable features such as |
21 | 23 | dynamically loaded modules that add additional commands. |
@@ -70,7 +72,7 @@ class ExampleApp(cmd2.Cmd): |
70 | 72 | """ |
71 | 73 | CommandSets are automatically loaded. Nothing needs to be done. |
72 | 74 | """ |
73 | | - def __init__(self, *args, **kwargs): |
| 75 | + def __init__(self, *args, auto_load_commands=True, **kwargs): |
74 | 76 | super().__init__(*args, **kwargs) |
75 | 77 |
|
76 | 78 | def do_something(self, arg): |
@@ -104,7 +106,7 @@ class ExampleApp(cmd2.Cmd): |
104 | 106 | """ |
105 | 107 | CommandSets with initializer parameters are provided in the initializer |
106 | 108 | """ |
107 | | - def __init__(self, *args, **kwargs): |
| 109 | + def __init__(self, *args, auto_load_commands=True, **kwargs): |
108 | 110 | # gotta have this or neither the plugin or cmd2 will initialize |
109 | 111 | super().__init__(*args, **kwargs) |
110 | 112 |
|
@@ -289,7 +291,7 @@ class LoadableVegetables(CommandSet): |
289 | 291 |
|
290 | 292 | class ExampleApp(cmd2.Cmd): |
291 | 293 | """ |
292 | | - CommandSets are automatically loaded. Nothing needs to be done. |
| 294 | + CommandSets are loaded dynamically at runtime via other commands. |
293 | 295 | """ |
294 | 296 |
|
295 | 297 | def __init__(self, *args, **kwargs): |
|
0 commit comments