<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 1, 2012 at 2:35 PM, Adam Spiers <span dir="ltr"><<a href="mailto:aspiers@suse.com" target="_blank">aspiers@suse.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">Doug Hellmann (<a href="mailto:doug.hellmann@dreamhost.com">doug.hellmann@dreamhost.com</a>) wrote:<br>
> On Mon, Apr 30, 2012 at 12:13 PM, Adam Spiers <<a href="mailto:aspiers@suse.com">aspiers@suse.com</a>> wrote:<br>
><br>
> > Dean Troyer (<a href="mailto:dtroyer@gmail.com">dtroyer@gmail.com</a>) wrote:<br>
> > > One of the first things to do is to find out who is interested in<br>
> > > contributing to this project.and hopefully coordinating some of the<br>
> > > work with the other emerging project-specific clients. Send me an<br>
> > > email and I'll build a list to get the discussion started.<br>
> ><br>
> > Count me in - by 'build a list' do you mean a new mailing list?<br>
> ><br>
> > I've read <a href="http://wiki.openstack.org/UnifiedCLI/HumanInterfaceGuidelines" target="_blank">http://wiki.openstack.org/UnifiedCLI/HumanInterfaceGuidelines</a><br>
> > (which looks like a great start on the topic!) and made some minor<br>
> > tweaks. Should we discuss the FIXMEs you marked here or elsewhere? I<br>
> > wanted to make a few suggestions before I forget - can always continue<br>
> > discussion elsewhere if appropriate:<br>
> ><br>
> > 1. Regarding "The subject names are always specified in command in<br>
> > their singular form. This is contrary to natural language use."<br>
> ><br>
> > - I didn't understand the second sentence here, but shouldn't the<br>
> > HIG should allow for scenarios where the verb can operate both on<br>
> > individual objects and on multiple objects in batch?<br>
><br>
> I read that as meaning the command to list instances available to a tenant<br>
> should be "list server" not the more natural "list servers".<br>
<br>
</div>Ah I see - makes sense now, thanks.<br>
<div class="im"><br>
> Can you give an example of a command that would work on multiple objects in<br>
> batch?<br>
<br>
</div>Things like<br>
<br>
openstack set hosts --name-matches='foo*' --maintenance enable<br>
<br>
# use with caution! would require confirmation prompt<br>
openstack delete images --name-matches='bar*'<br>
<div class="im"><br>
?<br>
<br>
> Running a cliff-based app without any arguments enters "interactive" mode<br>
> (as of 0.4) which gives the user a new prompt and lets them run multiple<br>
> commands before exiting. This is intended to be used as an optimization for<br>
> commands to cache authentication credentials and clients and avoid logging<br>
> in for every sub-command.<br>
<br>
</div>I love it :-) I guess it has readline support and could also offer<br>
completion too?<br></blockquote><div><br></div><div>Yes, it uses cmd2 for the interaction, so readline is supported, where available.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Forgive the newbie question, but does cliff have significantly<br>
different goals or scope to cement? I attended the Quantum CLI<br>
rewrite session at the summit:<br>
<br>
<a href="http://folsomdesignsummit2012.sched.org/event/b20c2743ac6ab35d4f33b4fcd1da4fa7" target="_blank">http://folsomdesignsummit2012.sched.org/event/b20c2743ac6ab35d4f33b4fcd1da4fa7</a><br>
<br>
and IIRC they were going to move to using cement. The notes from that<br>
session start on line 224 of:<br>
<br>
<a href="http://etherpad.openstack.org/quantum-folsom" target="_blank">http://etherpad.openstack.org/quantum-folsom</a><br>
<br>
In particular note: "Need to do some cleanup before the One CLI to<br>
Rule Them All project is going to be far enough long to be usable for<br>
Quantum commands". I wasn't sure how the work with cement would<br>
dovetail with this project though.<br></blockquote><div><br></div><div>Dean and I looked at cement and didn't feel it was a good fit (also, it looked like it would be cumbersome to use). cliff is a new framework that more directly meets the requirements we have, especially giving extensions the ability to load new commands dynamically.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> Since we're using argparse for the subcommands, the default behavior if a<br>
> command is run without arguments depends on the subcommand. If the<br>
> subcommand has no required arguments, it will do whatever it is meant to<br>
> do. If it does require arguments and sees none, argparse prints an error<br>
> message about whatever is missing<br>
<br>
</div>Agreed, except ...<br>
<div class="im"><br>
> (and possibly suggests that the user use --help to get<br>
> instructions).<br>
<br>
</div>One of my pet peeves is commands which tell you that you screwed up<br>
but don't immediately offer help so you can take appropriate remedial<br>
action. In other words, bearing in mind Dean's section on<br>
"User-Centered Design" in the HIG, I'd prefer a command outputted<br>
usage text along with an error than one or two sentences forcing you<br>
to rerun the command with the --help option.<br>
</blockquote></div><br></div><div class="gmail_extra">We can probably make them print help by default.</div>