Mailing-List: contact dev-help@mesos.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@mesos.apache.org
MIME-Version: 1.0
In-Reply-To: <CAFt=RON9tQBR+NK5cdh1HScp2-nc8C-TCAQ=Js98M2UG-e4wBA@mail.gmail.com>
References: <CAAQteBxs_MzuAGL7FpXRJPD7aRgaNtSdVgBSgj=g924ZQmatwQ@mail.gmail.com>
 <OF96046CF0.D6A9CBC4-ON48257FD8.00126E20-48257FD8.00129957@notes.na.collabserv.com>
 <CAJA-XLOBJqrGdX6jBRS4gW+mkrCxOVS1zD61KkCLrVkN4sUdNg@mail.gmail.com>
 <CANMwFmU95yh4Rc0AYoM9ZKRtr5EeBkE45LVXVNv=o55f3C9rPw@mail.gmail.com>
 <CAAQteBwdMTvX2DDcWEfc0zQS1Wo2FCf=8JgL+FKZuNmjmKeEDw@mail.gmail.com>
 <CAJR1fVquD-pf=2=ANrWuzWBMbfM-RWJpf_Jd03z+9nfLap4GiQ@mail.gmail.com>
 <CAMHxVRGLPwiHceJEoc71+1uKxDp5neNEcinsPqwppPbqEN=FQA@mail.gmail.com>
 <CANntcz457hV-HH-vOaDb6spbt=vWSxtGJ9TQU_P1Ws6FfxSRYQ@mail.gmail.com>
 <CANyrgvc3=JkBCOQ_RUbQ7=xT2rjfomsAcUQitBJ6Laftj5RKEQ@mail.gmail.com>
 <CAFp_Nivk8ETdJsf8C=9hD50rJfMZu=Fe0jqS5qb3AbdAh2=S2Q@mail.gmail.com>
 <OFAE7A7C63.361EEE4C-ON48257FDA.00022A01-48257FDA.00023F38@notes.na.collabserv.com>
 <CAKgKkU5K7v9twL0DBqUWzHXbcav=6_wC+RW1Z9_SoTU+3kjrOw@mail.gmail.com>
 <CAJR1fVqTnVxvXuon6k=5P=yx0DxPdHZKkDdW4tBbEyykt1j_6Q@mail.gmail.com>
 <CAKgKkU4O4PpOz1K=C8mt6XK2O5Kit-3wOmH0HsyM+5Po71g3ZA@mail.gmail.com>
 <CAJR1fVreAWaxKSdjePCpHPrt0iiBHcZYH6M8vg4zdT_t6y3_Aw@mail.gmail.com>
 <CAOs_uxwTL6_=Zv8e2Pbn4hP3sLTvZsZzneDVcQfdkWShx7vAAA@mail.gmail.com>
 <CAMHxVRHt-QqTZKFXACe66y6byO-VVd_vOCOZvRN05WYc+be=8A@mail.gmail.com>
 <CAOs_uxwwf18uNnSb+Vb782ww7RPNhZrM4LqbVsQJQQpTG=QnHA@mail.gmail.com>
 <CAJA-XLOizSt5JeHrGos0FLeQa0Ufe1A-c8HFQFqdg8W0LDmzSg@mail.gmail.com> <CAFt=RON9tQBR+NK5cdh1HScp2-nc8C-TCAQ=Js98M2UG-e4wBA@mail.gmail.com>
From: Artem Harutyunyan <artem@mesosphere.io>
Date: Fri, 24 Jun 2016 09:35:42 -0700
Message-ID: <CAMrTJS-2wTewuGXFuV4hZ36OhespbePrEo_cEzBMNLODYL0skw@mail.gmail.com>
Subject: Re: Mesos CLI
To: dev@mesos.apache.org
Content-Type: multipart/alternative; boundary=001a11409d8e20e4b3053608c420
archived-at: Fri, 24 Jun 2016 16:36:15 -0000

--001a11409d8e20e4b3053608c420
Content-Type: text/plain; charset=UTF-8

Having the CLI package outside the Mesos repo will make it very hard for
Mesos developers to verify whether the change that they're introducing
breaks the CLI or not. In practise no one is going to actually do that and
so the CLI will just sit there and slowly degrade. It will also make it
virtually impossible to package it together with Mesos, and someone will
need to maintain a compatibility table between CLI and Mesos versions.

I am also a +1 for python. Users shouldn't care as long as we can package
it as a binary. As for developers, it's naive to expect that there will be
a consensus, both sides have very strong advantages and drawbacks. So we
need to come to a compromise.

I would suggest that Kevin and Haris make a live demo of the functionality
that's already in place during our next community sync. This way everyone
we'll be able to see what they already have, and we collectively will be
able to estimate how long will it actually take us to re-implement all of
that in C++. It would be great to see everyone who has an opinion about
this join the community sync and express it.

Artem.

On Thu, Jun 23, 2016 at 7:40 PM, haosdent <haosdent@gmail.com> wrote:

> IMO, I perfer to C++ if we decide to put CLI in Mesos repo.
> Because we have a lot of utils in stout and libprocess, I think we could
> reuse most of them when implementing CLI.
> So it would be effective in development as well. If not utils classes and
> functions in stout/libprocess meet our requirements. We could add
> them and the whole Mesos code would get benefits after adding these C++
> utils classes and functions. Comparing to implement CLI by
> Python/Golang or other languages, seems they could not bring too much
> benefits.
>
> But If we decide to put CLI outside Mesos repo. I perfer to use Python or
> Golang as the reasons @Guangya and @tommy mentioned above.
>
>
> On Fri, Jun 24, 2016 at 10:06 AM, tommy xiao <xiaods@gmail.com> wrote:
>
> > 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 <gyliu513@gmail.com>:
> >
> > > 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 <yujie.jay@gmail.com> 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 <gyliu513@gmail.com>
> > 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 <klueska@gmail.com>
> > > 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
> >
>
>
>
> --
> Best Regards,
> Haosdent Huang
>

--001a11409d8e20e4b3053608c420--