Order of options / command name seems to matter

[marktheunissen]

Hello,

If I have options, it seems to be mandatory that they appear before the command name, as putting them after triggers a 'no such option' error.

Test code:

import click

@click.group()
@click.option('--abc', default=2)
@click.option('--defg', default=2)
def cli(abc, defg):
    click.echo('Options passed were %s / %s' % (abc,defg))

@cli.command()
def sync():
    click.echo('Synching')

if __name__ == '__main__':
    cli()

This doesn't work:

$ test.py sync --defg=6
Options passed were 2 / 2
Error: no such option: --defg

This works:

$ test.py --defg=6 sync
Options passed were 2 / 6
Synching

It may be that the options must come before the command, but then for example I see in one of the tests:

Usage: foo test [OPTIONS]

And I also have received a message before saying Usage: <script> command [OPTIONS] where the options were listed last in the list.

Perhaps just a better error message instead of no such option?

Thanks!
Mark

[marktheunissen]

On version 3.3, I see the different ordering recommended in the Usage help text:

$ test.py sync --defg=6
Options passed were 2 / 2
Usage: test.py sync [OPTIONS]

Error: no such option: --defg

[untitaker]

Duplicate of #108, see explanations there.

[marktheunissen]

Thanks. This issue could remain open to perhaps add a better error message, as I spent ages trying to figure this out. Change it to:

Error: no such option on the command, perhaps it is a group option?

[mitsuhiko]

This is intentional.