I am actually fine with Python as long as we can figure out a way to install python executable without any dependency during make install (and subsequently bundle it into rpm/deb packages). According to Kevin, looks like pyinstall can achieve that.
If we go for the Python route, I'd like to have a style guide for our python code. Looks like we can directly use the google python style guide <https://google.github.io/styleguide/pyguide.html>. Looks like pylint can also check the style automatically. - Jie On Thu, Jun 23, 2016 at 1:21 AM, Guangya Liu <[email protected]> wrote: > +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. > > >
