mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Klues <klue...@gmail.com>
Subject Re: Mesos CLI
Date Thu, 23 Jun 2016 01:34:37 GMT
>
> 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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message