Motivation
Python is an ideal language for certain types of software infrastructure automation for a variety of reasons:
It has a community-accepted style guide (PEP 8), adherence to which makes it easy for software engineers to transition between projects and come up to speed quickly and easily.
It has a powerful and feature-rich testing framework (pytest), enabling comprehensive automating testing of a code base.
There are documentation guidelines and tools (PEP 257, Google docstring format, Sphinx), along with an established community history of thorough package documentation.
Various linters exist (Ruff) to automate and enforce adherence to much of the above.
The language is object oriented, enabling the development of ecosystems of modular, reusable components.
Automating what a user does manually often involves walking through a series of stages. E.g., first we need to do this one thing, then we need to do this other thing, and finally wrap up with this third thing. Each conceptual stage has the same general form, where you may wish to execute certain actions at the beginning or end of each stage, to check certain pre- or post-conditions before/after execution, etc. See The Conceptual Stage for more details.
In such scripts, you often need to execute commands in the underlying
shell. Bash alone is less than ideal for such robust scripting, because
it lacks many of Python’s features listed above.[1] When you
need to use Python to interact with the underlying shell, the
subprocess library exists; however, it’s laser-focused on just
providing shell interaction, and users often wind up writing little
wrappers around it to add functionality or convenience for their
particular use cases.
The questions then are:
Can we create a tool to help ease the development of such automation scripts?
Can it be easy to get started with, but also provide substantial power-user functionality?
staged-script is just such a tool.
Footnotes