<div dir="ltr">Some feedback<div><br></div><div>If we have a debug command we should just show the debug commands. If we don't want users to have them ootb they should be plugins then I would think. This assumes the commands can't  do anything destructive or otherwise harm a running model/etc by being run. </div><div><br></div><div>The get is there because of the set. Some things are read/write properties and those are get/set. list vs show is meant to be around entities in the Juju model. You can list them to see tabular output of info about the entity and you can show them for single details. I appreciate the config case seems odd, but config isn't a root model entity, it's a property and you can set that and you can't set other entities in the model. I think it makes sense to keep these. </div><div><br></div><div>The list one is tricky. list is there to be consistent, help users discover entities in the model (list-<tab>), and to help easily see things in the help text as it jumps out as a common pattern (you can list, show, etc things). However, it was agreed that leaving off the list should default to the list output. It reads nicer and seems to make the most sense for users that know enough Juju to know what they're doing. </div><div><br></div><div>With that in mind, hiding them behind an --alias or what not seems counter productive. It's not there in the main output for new users, the ones we're aiming to serve. With this in mind, it makes the most sense to just remove them then, which I don't personally like, but I think makes things the most clean and with the most consistent story. </div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, May 25, 2016 at 2:52 PM Nate Finch <<a href="mailto:nate.finch@canonical.com">nate.finch@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">+1 ... one and only one way to do something is a lot easier to understand.  Either we like juju list-foos or we like juju foos... pick one and move on.  This feels like two camps agreed to disagree and just kept both. </div><div dir="ltr"><div><br><div class="gmail_quote"><div dir="ltr">On Wed, May 25, 2016 at 10:12 AM Katherine Cox-Buday <<a href="mailto:katherine.cox-buday@canonical.com" target="_blank">katherine.cox-buday@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
I think this has come up before on this list, but: isn't having 2 sets of commands in the first place a design smell? If we need aliases because users aren't using the originals, then  shouldn't we fix the original commands?<br>
<br>
Tim Penhey <<a href="mailto:tim.penhey@canonical.com" target="_blank">tim.penhey@canonical.com</a>> writes:<br>
<br>
> On 25/05/16 00:12, Marco Ceppi wrote:<br>
>> Even if you don't expect people to run them, hidding them seems<br>
>> awkward.<br>
>> Better to simply educate with good help output about what the<br>
>> command<br>
>> does and when/why use the command.<br>
><br>
> Was thinking, perhaps it would be better to have a feature flag to use<br>
> the "hidden" commands instead of the ability to hide commands.<br>
><br>
> If you set the feature flag, you get the additional commands, and they<br>
> show up in help etc.  That way a way to get users to run them could be<br>
> something like:<br>
><br>
>   JUJU_FEATURE_FLAGS=dev-debug juju dump-model<br>
><br>
> or something like that.<br>
><br>
> Tim<br>
<br>
--<br>
Katherine<br>
<br>
--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</blockquote></div></div></div>
--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</blockquote></div>