also support command names with hyphens

[karenetheridge]

..by mapping them to the equivalent underscore command class

Summary

mojo my-command will now look for MyApp::Command::my_command, not just ::my-command.

Motivation

kebabs are tastier than snakes on the command line

References

as discussed on irc today, 2019-06-24.

[CandyAngel]

You can squash the "fix" commit into the original one, as it makes the history tidier.

[kiwiroy]

Why not Mojo::Util::camelize

$ perl -MMojo::Util=camelize -E 'say camelize q{my-command}'
My::Command

[karenetheridge]

@kiwiroy my-command -> My::Command is a very different transformation than to my_command. I'm not sure what you're suggesting here.

[kiwiroy]

@karenetheridge hmm, it is. I forget \w includes _ so snakes are already accepted. Also my question would infer a breaking change.

[kraih]

Should underscore commands also show up with hyphens in the command list?

$ mojo generate
Usage: APPLICATION generate GENERATOR [OPTIONS]

  mojo generate app
  mojo generate lite_app

Generators:
 app       Generate Mojolicious application directory structure
 lite_app  Generate Mojolicious::Lite application
 makefile  Generate "Makefile.PL"
 plugin    Generate Mojolicious plugin directory structure

See 'APPLICATION generate help GENERATOR' for more information on a specific
generator.

[karenetheridge]

Should underscore commands also show up with hyphens in the command list?

Possibly. Where would be a good place to list them? If they get their own line, the help list would grow a lot if most of the commands had underscores .

Maybe this instead (using my app as an example as it has some underscore commands)?

bin/conch --help
Usage: APPLICATION COMMAND [OPTIONS]

  mojo version
  mojo generate lite_app
  ./myapp.pl daemon -m production -l http://*:8080
  ./myapp.pl get /foo
  ./myapp.pl routes -v

Tip: CGI and PSGI environments can be automatically detected very often and
     work without commands.

Options (for all commands):
  -h, --help          Get more information on a specific command
      --home <path>   Path to home directory of your application, defaults to
                      the value of MOJO_HOME or auto-detection
  -m, --mode <name>   Operating mode for your application, defaults to the
                      value of MOJO_MODE/PLACK_ENV or "development"

Commands:
 cgi                      Start application with CGI
 check_layouts            Check for conflicts in existing rack layouts (also check-layouts)
 check_validation_plans   check all validations and validation plans (also check-validation-plans)
 clean_permissions        Clean up unnecessary permissions (also clean-permissions)
...

[kraih]

I imagine it wouldn't show the underscore versions at all then.

[CandyAngel]

I don't mind this as a quality-of-life thing[1], but I'd prefer the documentation and command listing to match the actual module name.

Though.. if both are allowed, documentation involving commands is going to end up as a mix of the two, depending what the author prefers. Not within Mojolicious itself, but articles written about it, command SYNOPSIS', etc.

As a side-note, as commands can start with underscores, this would allow commands like
script/app -xyz -c app.conf
which is visually confusing. Not that anyone should be doing that though! :P

I don't usually have multi-word commands, they end up as subcommands. For example, with the generate command, app would be a subcommand with full and lite subcommands under that.

[1] I say, then proceed to list a bunch of objections and concerns.. :)

[karenetheridge]

as commands can start with underscores, this would allow commands like
script/app -xyz -c app.conf

oooh. The more I stare at this the more I can't decide if this is something that should be disallowed, or could be a really nifty feature... I am not evil enough to divine interesting ways this could be abused.

I have no objections to not changing the 'help' text at all, simply silently accepting an alternate spelling for the command.

[jhthorsen]

I'm neutral to this change.

[kraih]

Commands starting with an underscore are a blocker for this feature.

[CandyAngel]

As this has headed into having to implement a breaking change (restricting command names) to introduce, my vote has changed to against.

It seems a bit excessive to restrict command names (and potentially break existing commands in the process) just to avoid the potential of having to use the shift key when typing a command. If your commands have more than one underscore, it may be of more benefit to refactor it into sub-commands.

bin/conch --help
Usage: APPLICATION COMMAND [OPTIONS]

Commands:
 cgi    Start application with CGI
 check  List available checks
 clean  List available cleaners

[karenetheridge]

Commands starting with an underscore are a blocker for this feature.

Could you clarify what you mean by this? Commands can start with an underscore now, can they not?

[CandyAngel]

Could you clarify what you mean by this? Commands can start with an underscore now, can they not?

It's a blocker because, if this is accepted, commands that start with an underscore look like dash options.

$ script/app -xyz -c app.conf # command is "_xyz"
$ script/app --login # command is "__login"
$ script/app --home # is this the "home" long option or the command "__home"?

Whereas currently, they would just look odd:

$ script/app _xyz -c app.conf # command is "_xyz"
$ script/app __login # command is "__login"
$ script/app __home # definitely the command "__home"

This is why it has been suggested that commands with leading underscores be prohibited, so it would no longer be a blocker for this change.

[karenetheridge]

This is why it has been suggested that commands with leading underscores be prohibited, so it would no longer be a blocker for this change.

Is that a request that I change the patch to do that? That wasn't clear to me. I have no objection to this either way.

[karenetheridge]

I have changed $name =~ tr/-/_/; to $name =~ s/(?<=.)-/_/g;.

[karenetheridge]

I have rebased this to the current master. Is there anything else I can do to make this more satisfactory?

[kraih]

Calling for a vote @mojolicious/core.

[kraih]

I vote 👎 on this proposal, since i fear more alternatives for how to specify commands might cause confusion. Even if in general i like foo-bar more than foo_bar for command names.

[marcusramberg]

I'm neutral, I like the foo-bar style too but I fear gotchas with this solution.

[Grinnz]

I'm neutral, it would be nice to support but I don't see a way to do it without potential for confusion.

[jhthorsen]

Same reasoning as @kraih. 👎 from me.