+1 to use python. By using python, we can debug the CLI without re-compile but just update the CLI file and debug it with pdb, this is very helpful to trouble shooting.
On Thu, Jun 23, 2016 at 9:34 AM, Kevin Klues <[email protected]> wrote: > > > > 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. >
