> > The best option may still be for it > to be in Python, this is why I'm asking if there are particular things that > our helper libraries don't provide which you are leveraging in python. >
One thing we rely heavily on that is missing is `docopt`. We use docopt for convenient / standardized command line parsing and help formatting. This makes it really easy to enforce a standard help format across plugins so the CLI has a consistent feel throughout all of its subcommands. Supposedly there is a C++ implementation of this now, but it requires gcc 4.9+ (for regex). https://github.com/docopt/docopt.cpp In addition to this, the plugin architecture we built was very easy to implement in python, and I'm worried it would be much more complicated (and less readable) to get the same functionality out of C++. The existing CLI has some support for "plugins" (by looking for executables in the path with a "mesos-" prefix and assuming they are an extension to the CLI that can exist as a subcommand). However, the implementation of this is pretty ad-hoc and error prone (though it could conceivably be redone to work better). To get the equivalent functionality out of C++ for the plugin architecture we've built for python, each plugin would need to be implemented as a shared object that we dlopen() from the main program. Each module would define a set of global variables describing properties of the plugin (including help information) as well as create an instance of a class that inherits from a `PluginBase` class to perform the actual functionality of the plugin. The main program would then load this module, integrate its help information and other meta data into its own metadata, and begin invoking functions on the plugin class. I'm not saying it's impossible to do in C++, just that python lends itself better to doing this kind of stuff, and is much more readable when doing so.
