Fixing "juju help commands"

[Rick Harding]

Some feedback

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.

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.

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.

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.

On Wed, May 25, 2016 at 2:52 PM Nate Finch <nate.finch at canonical.com> wrote:

> +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.
>
> On Wed, May 25, 2016 at 10:12 AM Katherine Cox-Buday <
> katherine.cox-buday at canonical.com> wrote:
>
>>
>> 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?
>>
>> Tim Penhey <tim.penhey at canonical.com> writes:
>>
>> > On 25/05/16 00:12, Marco Ceppi wrote:
>> >> Even if you don't expect people to run them, hidding them seems
>> >> awkward.
>> >> Better to simply educate with good help output about what the
>> >> command
>> >> does and when/why use the command.
>> >
>> > Was thinking, perhaps it would be better to have a feature flag to use
>> > the "hidden" commands instead of the ability to hide commands.
>> >
>> > If you set the feature flag, you get the additional commands, and they
>> > show up in help etc.  That way a way to get users to run them could be
>> > something like:
>> >
>> >   JUJU_FEATURE_FLAGS=dev-debug juju dump-model
>> >
>> > or something like that.
>> >
>> > Tim
>>
>> --
>> Katherine
>>
>> --
>> Juju-dev mailing list
>> Juju-dev at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160526/7d39724d/attachment.html>