Double-dash separator can be used between group name and commands, has odd behavior

[sirosen]

This is not a bug, but an enhancement request -- I'd like to be able to turn off this behavior.

Right now, Click allows a group name and a command name to be separated using the -- separator.
I think this is confusing, and I would like it to raise an error in my CLI.

To explain and provide an example, imagine a command group foo with a command in it named bar.
You can write

$ foo bar --help

and things are happy.

You can also write

$ foo -- bar

and things work fine.
This behavior makes sense in my head, because bar is a positional argument to foo in a sense, but things are about to get messy and weird.

$ foo -- bar --help

This works, producing help output, and it really looks to me like it shouldn't. I guess the parsing for bar comes into play when it's read by foo and -- is just forgotten? I'm not sure.

I would like to entirely disable the usage of -- within the command tree. That is, I think it should be usable after a command name, but not between a group and a command.
So, foo -- ... should be entirely disallowed because it's a group. The only reason to use -- is to pass things like --help as arguments, and the parsing behavior here is confusing.
I don't see a viable use-case for writing foo -- bar ... over foo bar -- ....

I could see this being added as an optional behavior, since making it the default will potentially break existing scripts.
In the meantime, is there some way that I can disable this for my own application in Click 5 or 6?
I'm also happy to write this and submit a PR, if I can get a little bit of direction on (1) where I should be looking to customize the parsing and (2) whether or not this is a feasible small change (vs. uprooting a lot of well-established code, which I'm somewhat averse to).

[jcrotts]

Feel free to submit a PR with your proposed change. However, I think it would be hard to make an API change this significant, because as you said it could break a lot of peoples existing code.

[wrcYuri]

Hi, I worked on this issue for quite a while and would like to submit a PR. In order to make the "Add an entry in CHANGES.rst summarizing the change and linking to the issue" point of checklist done there are questions:

1. Is it enough to write 'Using double-dash separator can be turned off. :issue:619' in CHANGES.rst?
2. Should some notes appear in docs/command.rst file?
   P.S. the relevant notes in docstrings and comments in the code are done.

[davidism]

Yes to both. Thanks for working on this!

[wrcYuri]

I've got fiew more questions, perhaps they are a little bit silly, but nevertheless:)
my local tox check showed some... problems. Tests succeded but there are those, which got skipped, because of my OS, and those about Python 3.6, 3.7, 3,8, pypy3, so my questions are:

1. Should I just install those interpreters to my machine and try again?
2. Skipped tests will work out later according to this: "CI will run the full suite when you submit your pull
   request"?
3. There are typing errors... but those which I am linked to are just 3 of them, these others in _winconsole.py, _compat.py, _termui_impl.py. Those files I haven't touched, excplicitly.
   Actually that is all.
   P.S. If I am asking in the wrong place, I would be grateful for the redirection :)

[davidism]

I'm hesitant to allow disabling this. Perhaps if there is very clear documentation around "If you disable this on a command, it will be impossible for your users to provide an argument that looks like an option. Make sure this situation will never come up before doing this." The developer would also need to disable this individually for every command they do not want it on. Each command in the nested processing handles parsing individually, so each one might take an argument that could look like an option, and it's impossible for a command to know it's the last one until after its processing is complete.

[wrcYuri]

Hello, David. Glad to hear you, although we have war in Ukraine today, I will try to focus...
I see your point, and yes you are wright about the individual case on each command. I thought about different scenarios too, but then decided to take a literally straight approach just to hear your opinion about this and to hear if that is enough or I should consider different use cases too. So, basically now I am all listening the technical task if there will be such one from you. Honestly speaking I don't understand the case when we need <group> <--> <subcommand>. I think that an option is an option explicitly when we have <command> <--option>.

[davidism]

What you implemented in your PR is a good solution for this issue, assuming that the issue should be addressed. I'm currently rewriting the parser, which is why I came back to this.

Without discussing whether this particular CLI design is good, consider the following setup.

@click.group()
@click.pass_context
@click.argument("path", type=click.Path())
def process(ctx, path):
    click.ensure_object(dict)["path"] = path

@process.command()
@click.pass_context
@click.option("--save")
def reformat(ctx, save):
    ...

Let's say you want to process a file whose name starts with a -, such as -example.py. You would need to be able to do the following: process -- -example.py reformat --save However, if -- isn't allowed (globally or for the group only), then it's impossible to specify the file, it will raise an "unknown option" error. And if -- is only allowed once, not per command, then --save will raise an "extra argument" error instead of being treated as the save option.

[sirosen]

As the OP, I want to mention something. When I filed this, we had just written a CLI application with click at work. I was concerned about ways in which users could confuse themselves, and tried all sorts of stuff like playing with -- to see what would happen.

In the 5+ years since then, I haven't seen a single user get mixed up by this behavior.

I think -- between a group and command is very odd. It would be preferable, IMO, to reject it. But I don't think this really needs to change, and have the aforementioned anecdotal data to back that up.

[davidism]

OK, based on the further discussion here, I'm going to close this.