2
Aldar
5y

Hey guys!
Once again, I got a little stumped when writing one thingmajig in Python.

I am normally not a programmer (Work as sysadmin), so I don't really know all the fancy abstract ways things are done "properly", which is why I need to ask here:

I have a program, separated into parts. The "core" is a part that sets commandline argument structure (using the argparse library), loads master configuration file, sets up the main logging facility, and then proceeds to load "plugins" - python files with one or more classes that implement one specific abstract class that forces them to implement a common interface of init, run, cleanup functions.

The core then proceeds to initialize those classes, run the "run" function, and run the "cleanup" function.

If the plugin class throws a Warning, it is only logged and runtime continues. If it is anything else, the program logs it and stops.

Now, the issue is, sometimes, a user may want to continue even if a non-warning occurs.

Lets say that I am creating a user, and the user already exists. Sometimes, the program user might want to continue with further plugin execution. And what I was told was to implement specific commandline switches that force continuation of runtime despite the plugin failing.

How should I implement it? The most obvious thing is to add a specific switch for every plugin, but that is exactly what I am trying to evade. I want to have the core as abstract as possible.

Other solution I thought of is to have a file of some sort that would list extra switches to implement, then it would be up to the class to implement if it uses the switch or not (I pretty much pass the entire Namespace received from parse_args() function), but this also feels kinda hackish.

I thought about having some sort of function that the plugin could call in the core to add a new argument, but at the point that plugins start loading, the argument parser is already compiled and cannot be changed further.

Any other ideas of how to re-implement the program are also welcome! I may not do it this times, but I'd at least learn something new again.

Comments
  • 2
    I would change the architecture to differentiate between notices, warnings, errors and fatal errors. Only fatal errors immediately exit, normal errors can continue if given the right cli option. The plugins obviously have to properly implement the right severity for the right problems. When a normal error occurs they check a flag whether they should throw a normal or fatal error. The flag could be given via a context object passed to the plugins run function
  • 0
    @12bitfloat That is exactly the idea I had.

    The issue is, however, the only way I can work with the CLI is by using commandline switches. And those, as I stated before, are compiled before plugins even start loading, as the program can be run both, interactively and by another tool in an infrastructure where interactive prompts aren't desired.
  • 0
    @Aldar Yeah it's just a global cli switch: "--severe-errors" or whatever
Add Comment