Even though I’m using the Discourse Docker setup for almost half a year now, it still happens to me that I swap the launcher parameters and I write
./launcher app enter
instead of
./launcher enter app
To make a long story short and end this frustration, I suggest making the launcher forgive swapped parameters…
This is a little weird it basically means all launcher commands are now disallowed as container names? Not that matching names isn’t confusing anyway, I grant you that…
No, I don’t see why this would mean that launcher command names are disallowed as container names: If the first parameter is a valid command, behavior will be the same as it is now. And if the first parameter is not a valid command, the current behavior is to exit 1 with an error message.
My PR only addresses the case where the first command is not a valid command name and the second command is a valid command name. In this case, it is probable that the user confused the parameter order.
For the sake of safety, we could prompt the user:
$ launcher app build
'app' is not a valid command name.
Did you mean 'launcher build app'? [Y/n]
Yes I like that much better! If you can make that change I vote we accept your PR.
There you go:
PS: Interesting: The first line (github.com/discourse/discourse_docker) links to the commit (= url that i posted here), whereas the subject line (FEATURE: Make launcher forgive swapped parameters) links to the PR. I’m sure that’s intended, but that just surprised me.
Nothing against making things more user friendly, but most of the few CLIs I’ve used simply output a type of > enter --help when I’ve used the wrong syntax.
“Nothing against” and “but” don’t work well together, so let me say this: Most of the few forum softwares I’ve used weren’t very usable, so why making Discourse a usable forum software?
The answer is: because we can do better.
I don’t know what you mean by that other than you must have misinterpreted what I meant it to say.
I did not mean that the code should not correct user error.
Simply that most CLIs detect user error and “point them in the right direction” instead of trying to correct it for them.
If it is easy enough to accept command arguments and options in different sequences, different grammar (eg. ./launcher -r -a), then yes, it should be done.
I am sorry, we have sat on this PR for 3 years now… and here I am rejecting it after 3 years.
My rational here for rejecting this is that our giant ball of bash is already so fragile and complex, I just want to be very very careful about adding new things here and this is another point of fragility we would need to worry about, we would have to update this section as we add commands.