Added 'no_args_is_help' to Command

[jdell64]

I added the no_args_is_help param to the Command class. I also created a test in test_commands.py:

def test_no_args_is_help_off(runner):
    @click.command()
    def cli():
        """This is the help."""
    result = runner.invoke(cli)
    assert 'This is the help.' not in result.output


def test_no_args_is_help_on(runner):
    @click.command(no_args_is_help=True)
    def cli():
        """This is the help."""
    result = runner.invoke(cli)
    assert 'This is the help.' in result.output

[jdell64]

If this isn't good enough for your code base, let me know what I can do to fix it.

[ammsa]

+1

[tony]

Can you rebase @jdell64 ?

[jdell64]

I'm really sorry, I'm new to this. Rebase?

On Tuesday, May 31, 2016, Tony Narlock notifications@github.com wrote:

Can you rebase @jdell64 https://github.com/jdell64 ?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#502 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AA0oYFhHlNZQhs_ehR0HxDd3gkSmCe3Vks5qG_pcgaJpZM4G_tJl
.

Richard J Tindell

Ps 102:18- "This will be written for the generation to come, That a people
yet to be created may praise the Lord."

[vinu76jsr]

https://help.github.com/articles/about-git-rebase/ @jdell64

[jdell64]

Would I be rebasing because they don't want it in their code base? I was told this was just 'bikeshedding' so they wouldn't merge my request in. (I may still be missunderstanding).

[untitaker]

Okay, I'll actually merge this in.

Please rebase (to resolve the branch conflicts), and also address the comments I'll make in the diff.

[untitaker]

@jdell64 Are you still interested in this? There is one inline comment that needs addressing. Thanks!

[jdell64]

Sure! I'll take a look

On Aug 28, 2016, at 6:02 PM, Markus Unterwaditzer notifications@github.com wrote:

@jdell64 Are you still interested in this? There is one inline comment that needs addressing. Thanks!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[untitaker]

This misunderstanding has occured in my own tooling: pimutils/todoman#48 (comment)

What do you think about adding a sentence like "See command subcommand --help for more information." to the short help string instead of adding a new flag?

[jdell64]

Hey, sorry, just got back around to your comment.

Do you still need me to do this?

[untitaker]

If you consider the alternative solution I proposed (see last comment) acceptable I would prefer it over the added no_args_is_help.

[jdell64]

Sounds good. I will try to get this done soon.

…

On Dec 2, 2016, at 4:28 PM, Markus Unterwaditzer ***@***.***> wrote: If you consider the alternative solution I proposed (see last comment) acceptable I would prefer it over the added no_args_is_help. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[iluxame]

@untitaker
In my opinion its better to show help message with empty command.
in case of a sentence like "See command subcommand --help" user will need 2 commands instead of one. However from other point of view it will be clear to user that he didn't entered any meaningful input.

This patch actually aligns command user experience with group user experience. It seems that similar experience is less confusing. So I would prefer @jdell64 approach.

[iluxame]

OK, since it seems that neither this PR or its rebased version #804 won't be merged, I've found the following WA useful:

def show_help_if_no_args(func):
    """
    This decorator shows meaningful message in case of no parameters passed
    to CLI callback
    TODO: to remove it when https://github.com/pallets/click/pull/804 will be
    merged
    :param func:
    :return:
    """
    @wraps(func)
    def inner(*args, **kwargs):
        # filter all None values,
        res = filter(lambda x: x is not None, kwargs.itervalues())
        # check if all values are boolean with False
        if len(res) == res.count(False):
            click.echo("No parameters passed please use -h/--help for usage")
            sys.exit(1)
        return func(*args, **kwargs)
    return inner

Than I use it this way: I'm placing it before decorator that passes context to callback (this way all parameters and options already caught by click):

 @click.command()
 @click.option(
     '-e', '--environment',
     type=click.Choice(['test', 'prod', 'stg', 'junit']),
     help='Kubernetes environment name')
 ....
 @show_help_if_no_args
 @BaseCLI.context() ### returns click.make_pass_decorator(Context, ensure=True)
 def create(ctx, **kwargs):

This is far from ideal since I need to deal with default values of parameters but it is working pretty well and it is simple.

[ShahriyarR]

If the domain, was printing help message if no options were passed, I have implemented simple one here:
#886

Maybe it will be helpful, if somebody looking for something similar. But it is still not the best solution in term of usability:

• It is checking all passed options manually to check if they are False or not. If all passed things are false then, it indicates there is no option passed and it is going to call print_help()
• I am passing None as param to print_help(ctx, param, value)

[roryhr]

An important feature of command line tools is they spit out a brief usage pattern and point you to more help. For example:

$ wget
wget: missing URL
Usage: wget [OPTION]... [URL]...

Try `wget --help' for more options.
$ curl
curl: try 'curl --help' or 'curl --manual' for more information

This makes programs self-documenting because you run it and see and see "ah, this is the expected usage pattern and here's how I get help". From there you're off to the races!

[untitaker]

@roryhr I can't tell whose side you're on, but to me this is actually a reason why I consider the current behavior to be fine. Just barfing out the help output in response to an invalid invocation seems like a too un-personal response to the user action.

[ThiefMaster]

A short help is nice, but getting the whole --help output is going to be extremely annoying in case of commands that have a very verbose help (httpie for example)