Not as much as a code review, but an architecture suggestion. Your code is fine, but I'm weary of the cleverness we tend to add when things grow more and more complex.

Unless you really want run everything from a single .py module, I'd suggest breaking up the program into multiple pieces. Have your shared pieces inside a common library and split the different groups into different executables, a bit like git and apt do - by calling external utilities. This also allows other people to easily write add-ons for your utility.

Think of utility verb --be-awesome as just calling utility-verb --be-awesome under the hood and passing whatever command line parameters it got. As a useful convention, you may want to have parameters that affect the base utility that could be stripped out of the command line when called or just force them to be placed between the utility and the verb parts. All utility-verb commands should be able to rely on the shared functionality on the library.

Not as much as a code review, but an architecture suggestion. Your code is fine, but I'm weary of the cleverness we tend to add when things grow more and more complex.

Unless you really want to run everything from a single .py module, I'd suggest breaking up the program into multiple pieces. Have your shared pieces inside a common library and split the different groups into different executables, a bit like git and apt do - by calling external utilities. This also allows other people to easily write add-ons for your utility.

Think of utility verb --be-awesome as just calling utility-verb --be-awesome under the hood and passing whatever command line parameters it got. As a useful convention, you may want to have parameters that affect the base utility that could be stripped out of the command line when called or just force them to be placed between the utility and the verb parts. All utility-verb commands should be able to rely on the shared functionality on the library.