Because the golang's popular, the golang is preferred as a cli build toolbox. anyone interesting it.
2016-06-24 10:01 GMT+08:00 Guangya Liu <[email protected]>: > 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. > > > > > > > > > > -- Deshi Xiao Twitter: xds2000 E-mail: xiaods(AT)gmail.com
