|
| 1 | +# Architecture |
| 2 | + |
| 3 | +The principal design challenge of [django-typer](https://pypi.python.org/pypi/django-typer) is to manage the [Typer](https://typer.tiangolo.com/) app trees associated with each Django management command class and to keep these trees separate when classes are inherited and allow them to be edited directly when commands are extended through the plugin pattern. There are also incurred complexities with adding default django options where appropriate and supporting command callbacks as methods or static functions. Supporting dynamic command/group access through attributes on command instances also requires careful usage of advanced Python features. |
| 4 | + |
| 5 | +The [Typer](https://typer.tiangolo.com/) app tree defines the layers of groups and commands that define the CLI. Each [TyperCommand](https://django-typer.readthedocs.io/en/latest/reference.html#django_typer.TyperCommand) maintains its own app tree defined by a root [Typer](https://django-typer.readthedocs.io/en/latest/reference.html#django_typer.management.Typer) node. When other classes inherit from a base command class, that app tree is copied and the new class can modify it without affecting the base class's tree. We extend [Typer](https://typer.tiangolo.com/)'s Typer type with our own [Typer](https://django-typer.readthedocs.io/en/latest/reference.html#django_typer.management.Typer) class that adds additional bookkeeping and attribute resolution features we need. |
| 6 | + |
| 7 | +[django-typer](https://pypi.python.org/pypi/django-typer) must behave intuitively as expected and therefore it must support all of the following: |
| 8 | + |
| 9 | +* Inherited classes can extend and override groups and commands defined on the base class without affecting the base class so that the base class may still be imported and used directly as it was originally designed. |
| 10 | +* Extensions defined using the plugin pattern must be able to modify the app trees of the commands they plugin to directly. |
| 11 | +* The group/command tree on instantiated commands must be walkable using attributes from the command instance itself to support subgroup name overloads. |
| 12 | +* Common django options should appear on the initializer for compound commands and should be directly on the command for non-compound commands. |
| 13 | + |
| 14 | +During all of this, the correct self must be passed if the function accepts it, but all of the registered functions are not registered as methods because they enter the [Typer](https://typer.tiangolo.com/) app tree as regular functions. This means another thing [django-typer](https://pypi.python.org/pypi/django-typer) must do is decide if a function is a method and if so, bind it to the correct class and pass the correct self instance. The method test is [is_method](https://django-typer.readthedocs.io/en/latest/reference.html#django_typer.utils.is_method) and simply checks to see if the function accepts a first positional argument named `self`. |
| 15 | + |
| 16 | +[django-typer](https://pypi.python.org/pypi/django-typer) uses metaclasses to build the typer app tree when [TyperCommand](https://django-typer.readthedocs.io/en/latest/reference.html#django_typer.TyperCommand) classes are instantiated. The logic flow proceeds this way: |
| 17 | + |
| 18 | +- Class definition is read and @initialize/@callback, @group, @command decorators label and store typer config and registration logic onto the function objects for processing later once the root [Typer](https://typer.tiangolo.com/) app is created. |
| 19 | +- Metaclass __new__ creates the root [Typer](https://typer.tiangolo.com/) app for the class and redirects the implementation of handle if it exists. It then walks the classes in MRO order and runs the cached command/group registration logic for commands and groups defined directly on each class. Commands and groups defined dynamically (i.e. registered after Command class definition in plugins) *are not* included during this registration because they do not appear as attributes on the base classes. This keeps inheritance pure while allowing plugins to not interfere. The exception to this is when using the Typer-style interface where all commands and groups are registered dynamically. A [Typer](https://django-typer.readthedocs.io/en/latest/reference.html#django_typer.management.Typer) instance is passed as an argument to the [Typer](https://django-typer.readthedocs.io/en/latest/reference.html#django_typer.management.Typer) constructor and when this happens, the commands and groups will be copied. |
| 20 | +- Metaclass __init__ sets the newly created Command class into the typer app tree and determines if a common initializer needs to be added containing the default unsupressed django options. |
| 21 | +- Command __init__ loads any registered plugins (this is a one time opperation that will happen when the first Command of a given type is instantiated). It also determines if the addition of any plugins should necessitate the addition of a common initializer and makes some last attempts to pick the correct help from __doc__ if no help is present. |
| 22 | + |
| 23 | +Below you can see that the backup inheritance example [Typer](https://django-typer.readthedocs.io/en/latest/reference.html#django_typer.management.Typer) tree. Each command class has its own completely separate tree. |
| 24 | + |
| 25 | + |
| 26 | + |
| 27 | +Contrast this with the backup plugin example where after the plugins are loaded the same command tree has been altered. Note that after the plugins have been applied two database commands are present. This is ok, the ones added last will be used. |
| 28 | + |
| 29 | + |
| 30 | + |
| 31 | +```python |
| 32 | + |
| 33 | + class Command(TyperCommand): |
| 34 | + |
| 35 | + # command() runs before the Typer app is created, therefore we |
| 36 | + # have to cache it and run it later during class creation |
| 37 | + @command() |
| 38 | + def cmd1(self): |
| 39 | + pass |
| 40 | + |
| 41 | + @group() |
| 42 | + def grp1(self): |
| 43 | + pass |
| 44 | + |
| 45 | + @grp1.group(self): |
| 46 | + def grp2(self): |
| 47 | + pass |
| 48 | +``` |
| 49 | + |
| 50 | +```python |
| 51 | + |
| 52 | + class Command(UpstreamCommand): |
| 53 | + |
| 54 | + # This must *not* alter the grp1 app on the base |
| 55 | + # app tree but instead create a new one on this |
| 56 | + # commands app tree when it is created |
| 57 | + @UpstreamCommand.grp1.command() |
| 58 | + def cmd3(self): |
| 59 | + pass |
| 60 | + |
| 61 | + # this gets interesting though, because these should be |
| 62 | + # equivalent: |
| 63 | + @UpstreamCommand.grp2.command() |
| 64 | + def cmd4(self): |
| 65 | + pass |
| 66 | + |
| 67 | + # we use custom __getattr__ methods on TyperCommand and Typer to |
| 68 | + # dynamically run BFS search for command and groups if the members |
| 69 | + # are not present on the command definition. |
| 70 | + @UpstreamCommand.grp1.grp2.command() |
| 71 | + def cmd4(self): |
| 72 | + pass |
| 73 | +``` |
| 74 | + |
| 75 | +```python |
| 76 | + |
| 77 | + # extensions called at module scope should modify the app tree of the |
| 78 | + # command directly |
| 79 | + @UpstreamCommand.grp1.command() |
| 80 | + def cmd4(self): |
| 81 | + pass |
| 82 | + |
| 83 | +``` |
| 84 | + |
| 85 | +```python |
| 86 | + |
| 87 | + app = Typer() |
| 88 | + |
| 89 | + # similar to extensions these calls should modify the app tree directly |
| 90 | + # the Command class exists after the first Typer() call and app is a reference |
| 91 | + # directly to Command.typer_app |
| 92 | + @app.callback() |
| 93 | + def init(): |
| 94 | + pass |
| 95 | + |
| 96 | + |
| 97 | + @app.command() |
| 98 | + def main(): |
| 99 | + pass |
| 100 | + |
| 101 | + grp2 = Typer() |
| 102 | + app.add_typer(grp2) |
| 103 | + |
| 104 | + @grp2.callback(name="grp1") |
| 105 | + def init_grp1(): |
| 106 | + pass |
| 107 | + |
| 108 | + @grp2.command() |
| 109 | + def cmd2(): |
| 110 | + pass |
| 111 | + |
| 112 | +``` |
| 113 | + |
| 114 | +## Notes on [BaseCommand](https://docs.djangoproject.com/en/stable/howto/custom-management-commands/#django.core.management.BaseCommand) |
| 115 | + |
| 116 | +There are a number of encumbrances in the Django management command design that make our implementation more difficult than it need be. We document them here mostly to keep track of them for potential future core Django work. |
| 117 | + |
| 118 | + 1) BaseCommand::execute() prints results to stdout without attempting to convert them |
| 119 | + to strings. This means you've gotta do weird stuff to get a return object out of |
| 120 | + call_command() |
| 121 | + |
| 122 | + 2) call_command() converts arguments to strings. There is no official way to pass |
| 123 | + previously parsed arguments through call_command(). This makes it a bit awkward to |
| 124 | + use management commands as callable functions in django code which you should be able |
| 125 | + to easily do. django-typer allows you to invoke the command and group functions |
| 126 | + directly so you can work around this, but it would be nice if call_command() supported |
| 127 | + a general interface that all command libraries could easily implement to. |
| 128 | + |
| 129 | + 3) terminal autocompletion is not pluggable. As of this writing (Django<=5) |
| 130 | + autocomplete is implemented for bash only and has no mechanism for passing the buck |
| 131 | + down to command implementations. The result of this in django-typer is that we wrap |
| 132 | + django's autocomplete and pass the buck to it instead of the other way around. This is |
| 133 | + fine but it will be awkward if two django command line apps with their own autocomplete |
| 134 | + infrastructure are used together. Django should be the central coordinating point for |
| 135 | + this. This is the reason for the pluggable --fallback awkwardness in shellcompletion. |
| 136 | + |
| 137 | + 4) Too much of the BaseCommand implementation is built assuming argparse. A more |
| 138 | + generalized abstraction of this interface is in order. Right now BaseCommand is doing |
| 139 | + double duty both as a base class and a protocol. |
| 140 | + |
| 141 | + 5) There is an awkwardness to how parse_args flattens all the arguments and options |
| 142 | + into a single dictionary. This means that when mapping a library like Typer onto the |
| 143 | + BaseCommand interface you cannot allow arguments at different levels |
| 144 | + (e.g. in initialize()) or group() functions above the command to have the same names as |
| 145 | + the command's options. You can work around this by using a different name for the |
| 146 | + option in the command and supplying the desired name in the annotation, but its an odd |
| 147 | + quirk imposed by the base class for users to be aware of. |
0 commit comments