Fixing "juju help commands"

[Rick Harding]

One more chunk of feedback, I think conversations like this can/should
happen on the main juju list. I know folks dump to dev a lot, but this is
something very public facing and has an impact on users.

On Thu, May 26, 2016 at 6:46 AM Rick Harding <rick.harding at canonical.com>
wrote:

> 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/f49c3f10/attachment.html>