Re: 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-), 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  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-bu...@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  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@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: list, show and get (was Re: Fixing "juju help commands")

[Nate Finch]

I can understand list-clouds vs show-cloud, for plural vs singular (even
though I don't think we actually have commands like that, with a plural and
a singular).  But show-config vs get-config seems really pedantic. You're
still showing one thing. One is a foo, one is a foo-config. They have very
easily differentiated names, unlike plural vs singular, which actually
might be confusing if they only differed by an s.

On Tue, May 24, 2016, 6:45 PM Tim Penhey  wrote:

> On 25/05/16 01:49, Nate Finch wrote:
> > While we're on the subject... we have list-foos, show-foos, and
> > get-foo... and I honestly cannot remember when to use which. Can we just
> > standardize on one, so no one has to remember if it's list-models or
> > show-models or show-model-config or get-model-config?  They all mean the
> > same thing, let's just pick one.
>
> 'list-foos' which is to be an alias for 'foos' returns a list of foos.
> 'show-foo' shows information about a single 'foo'
> 'get-foo' gets configuration about a particular 'foo'
>
> This is consistent across all our foos now.
>
> Tim
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Fixing "juju help commands"

[Tim Penhey]

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

--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Fixing "juju help commands"

[Nate Finch]

If there are things we really don't want uses to run, they should probably
just not exist in production builds. If they're just less-used commands,
then I don't think it's a big deal to have them in juju help commands.

If we want to remove them from production builds, they could either be
compiled out by default, or just made into plugins.  But I don't think
hiding is really a good idea.

I am +1 on removing aliases from the default output of juju help commands,
though.  It's really long and spammy right now, and half of the length is
just due to aliases.

I do like the idea of every juju list-foos having an alias of juju foos...
but then why even have list-foos at all?

While we're on the subject... we have list-foos, show-foos, and get-foo...
and I honestly cannot remember when to use which. Can we just standardize
on one, so no one has to remember if it's list-models or show-models or
show-model-config or get-model-config?  They all mean the same thing, let's
just pick one.
On Tue, May 24, 2016, 8:12 AM Marco Ceppi  wrote:

> On Tue, May 24, 2016, 12:19 AM Tim Penhey 
> wrote:
>
>> Hi folks,
>>
>> More from the "let's fix the output" school of thought.
>>
>> One thing that has bugged me about 'juju help commands' was the repeated
>> mentions of "alias for ".
>>
>> I propose that we don't show aliases by default, and allow the user to
>> task for them.
>>
>> Also, the supercommand describe commands method was written before I
>> knew about the tabular output, so some code could be cleaned up there.
>>
>> Proposal:
>>
>> juju help commands
>>- shows the commands that are neither aliases, nor hidden
>> juju help commands --alias
>>- shows either just the aliases, or everything including aliases
>> juju help commands --all
>>- shows basic commands, aliases and hidden commands.
>>
>> I'd like to add the ability to say a command is hidden so it doesn't
>> show up in the commands list. The purpose for these could be debugging
>> assisting type functions, like "dump-model" or "debug-controller" (two
>> commands that don't yet exist).
>>
>
> I don't see a need for this, I and other users often use juju help
> commands to find or remind me of these commands. If you expect users to run
> these debug/dump commands ever, show them.
>
> 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.
>
>
>> Thoughts?
>>
>> Tim
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Fixing "juju help commands"

[Tim Penhey]

Hidden would be a primitive defined in the github.com/juju/cmd package, 
whereas the "blockable" consideration is an implementation detail of 
juju commands.


I don't think we should specify them the same way.

However, that doesn't mean that Juju shouldn't have a base blockable 
command which the commands that could be blocked would use.  Just a thought.


Tim

On 24/05/16 16:31, Anastasia Macmood wrote:

Tim

If you are adding the ability to specify commands as "hidden", we may
greatly benefit from specifying commands as "blockable" too

Sincerely Yours,

Anastasia

On 24/05/16 14:19, Tim Penhey wrote:

Hi folks,

More from the "let's fix the output" school of thought.

One thing that has bugged me about 'juju help commands' was the
repeated mentions of "alias for ".

I propose that we don't show aliases by default, and allow the user to
task for them.

Also, the supercommand describe commands method was written before I
knew about the tabular output, so some code could be cleaned up there.

Proposal:

juju help commands
   - shows the commands that are neither aliases, nor hidden
juju help commands --alias
   - shows either just the aliases, or everything including aliases
juju help commands --all
   - shows basic commands, aliases and hidden commands.

I'd like to add the ability to say a command is hidden so it doesn't
show up in the commands list. The purpose for these could be debugging
assisting type functions, like "dump-model" or "debug-controller" (two
commands that don't yet exist).

Thoughts?

Tim





--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Fixing "juju help commands"

[Anastasia Macmood]

Tim

If you are adding the ability to specify commands as "hidden", we may
greatly benefit from specifying commands as "blockable" too

Sincerely Yours,

Anastasia

On 24/05/16 14:19, Tim Penhey wrote:
> Hi folks,
>
> More from the "let's fix the output" school of thought.
>
> One thing that has bugged me about 'juju help commands' was the
> repeated mentions of "alias for ".
>
> I propose that we don't show aliases by default, and allow the user to
> task for them.
>
> Also, the supercommand describe commands method was written before I
> knew about the tabular output, so some code could be cleaned up there.
>
> Proposal:
>
> juju help commands
>   - shows the commands that are neither aliases, nor hidden
> juju help commands --alias
>   - shows either just the aliases, or everything including aliases
> juju help commands --all
>   - shows basic commands, aliases and hidden commands.
>
> I'd like to add the ability to say a command is hidden so it doesn't
> show up in the commands list. The purpose for these could be debugging
> assisting type functions, like "dump-model" or "debug-controller" (two
> commands that don't yet exist).
>
> Thoughts?
>
> Tim
>


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Fixing "juju help commands"

[Tim Penhey]

Hi folks,

More from the "let's fix the output" school of thought.

One thing that has bugged me about 'juju help commands' was the repeated 
mentions of "alias for ".


I propose that we don't show aliases by default, and allow the user to 
task for them.


Also, the supercommand describe commands method was written before I 
knew about the tabular output, so some code could be cleaned up there.


Proposal:

juju help commands
  - shows the commands that are neither aliases, nor hidden
juju help commands --alias
  - shows either just the aliases, or everything including aliases
juju help commands --all
  - shows basic commands, aliases and hidden commands.

I'd like to add the ability to say a command is hidden so it doesn't 
show up in the commands list. The purpose for these could be debugging 
assisting type functions, like "dump-model" or "debug-controller" (two 
commands that don't yet exist).


Thoughts?

Tim

--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev