Yeah, ideally the project would also support bash auto completions.

If you are going to use Python optparse module then you can use optcomplete
module which knows how to complete all the command options. For example, we
use it in our rackspace-monitoring-cli library -
https://github.com/racker/rackspace-monitoring-cli/blob/master/contrib/optcomplete.sh
.

On Fri, Mar 30, 2012 at 10:05 PM, Roman Bogorodskiy
<[email protected]>wrote:

>  Vartolomei Nicolae wrote:
>
> > Hello,
>
> Hi,
>
> > I'm looking for a mentor for this task
> https://issues.apache.org/jira/browse/LIBCLOUD-160.
> >
> > Reffering to task, Roman's library looks good, the idea to build a
> "framework"
> > is good, so that we could almost plug lc-code to it, but I think it's
> better to rewrite
> > lc-code morphing it to a "framework".
> >
> > Since all libcloud code is modular we have just to write interface over
> it
> > this is why I keep quoting "framework".
> >
> > The main problem and the important one is to figure out commands
> structure".
>
> I think we can use Tomaz's suggestion as a starting point:
>
> libcloud <api> <resource> <action>
>
> This kind of stuff should be more or less automatic, meaning that adding
> new action to libcloud should not require writing (much) new code to add
> that to command line interface.
>
> This, however, is not enough to create a tool with good user experience,
> because command will be long, a lot of stuff has to be specified by
> user, etc.
>
> So, it would be reasonable to add some sort of presentation layer. This
> of how aliases could be configured in git. A reasonable aliases should
> be provided by the tool and it should be possible for user to inherit
> the default settings and add stuff on top of it.
>
> The also applies to output formatting: user should have an ability to
> customized the information returned by the tool: e.g. if user requests a
> node list, it should be possible to see what attributes to display.
>
> One more important thing to remember is that each driver has some
> specific functionality that typically could be used by calling ex_*
> methods or passing 'ex_*' arguments to the standard methods.
>
> Without that real life usage of the command line interface would be
> kind of limited (at least for some cloud providers) in my experience.
>
> > ps. I'm trying to get in touch with Roman to see his opinion about this.
> >
> > Got response from Roman, he is ready to help at those tasks.
> >
> > pps. i'm fluent russian speaker, we understood each other in 2 seconds :)
> >
> > Nicolae Vartolomei,
> > http://nvartolomei.com/
> >
>
> Roman Bogorodskiy
>

Reply via email to