Implementation details¶
It has become abundantly clear, that with enough eyes on the code, all bugs are deep. Typos and off by one errors will be fixed by people casually browsing the code base, but deeper structural problems will remain. Few read the entire source and fewer still understand its structure. Over time, these problems worsen as contributors unfamiliar with the code base bolt features on to the side with little planning or understanding. It is for this reason that I have chosen to document subuser’s architecture and I kindly request that you skim over this documentation before getting out the ducktape.
Basic file layout¶
The subuser source is stored in the logic directory.
- logic/subuser - This is the main subuser executable.
- logic/subuserCommands - This is where individual built in subuser cli utilities/subcommands are found.
- logic/subuserlib - The source files found in this directory are a mixture of sparse utility functions and major functions which touch multiple classes and data structures.
- logic/subuserlib/classes - This is where subuser class modules are stored.
Execution model¶
When you run subuser, a subuser executable is called which immediately passes execution on to a subuser command. Any executable found in the directory logic/subuserCommands is a subuser command. Any executable which is in the system path and starts with the string subuser- is also a subuser command. This makes it easy to add new subuser commands to the subuser cli. This model was taken from git.
Class structure¶
Subuser is written in Python with an object oriented architecture. The main data structure in subuser is a tree of objects. The base object is a subuserlib.classes.user.User object.
