Previously we separated commands as plugins. We also prepared the interpreter so that commands may be provided to it. I will look into implementing a plugin loader in this part of the series.
Rationale of Plugin Loader
Previously it was decided that the plugins will be stored in a specific directory (ie. commands) and that each plugin is contained in a directory of its own (ie. help).
Each plugin is structured so that a file matching to the name of the directory contains the actual logic. This logic is contained in a class that is named according to file (ie. help.py module contains Help class). A plugin class may provide a match method and it has to provide an execute method. The signature of an execute method may vary based on the needs of the plugin (ie. currently it supports commands and variables parameters).
Initial Tests and Implementation
This should be enough information for us to start design tests for the plugin loader. Here are the initial ones I came up with (note the mocking approach):
And here's the implementation:
Note that the files belong to the same package as the interpreter (ie. you should have placidity/plugin_loader.py and placidity/tests/test_plugin_loader.py in your file structure now).
Summary
As you can see from the test, our implementation expects certain kind of way to handle file system. So, surprise, surprise, we get to implement a new module that provides it! I will take a look at that in the next part of the series. You may find the source code of this part here.