Another advantage for using python is that we can use stevedore <http://docs.openstack.org/developer/stevedore/tutorial/loading.html> to manage all of the CLI plugins for container, agent,cluster etc. The stevedore was been widely used in OpenStack.
Thanks, Guangya On Fri, Jun 24, 2016 at 9:56 AM, Jie Yu <[email protected]> wrote: > 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. > > > > > >
