Added help_if_bare directive to print usage if command called with no options or arguments

[dennisjbell]

Most of my command line utilities take subcommands or required options, and by default, I print the usage if only the bare command is executed. This PR extracts this pattern into a directive for simple reuse.

I used the directive name 'help_if_bare' -- I'm open to changing this if you can think of a more concise and clear manner. I had also toyed with 'default_help' and 'help_on_no_arguments', but to be honest, at this point they're all ceasing to be meaningful, in the same way that if you say the same word over and over again, it stops sounding like a word -- I could really use a second opinion.

Thanks for providing methadone -- it has made life much better for me. I was just about to provide pull requests for a simpler version and not needing to put main at the top, but I see that you beat me to it with v1.3.0!

[davetron5000]

Glad you're using it! I have a couple of reservations, none of which are related to the code (which looks great - thanks for including tests):

• Methadone wasn't intended to do command-based CLI apps (I would use GLI, which I created, but there are others like Thor).
• That said, you might be able to achieve this by using arg, as in arg 'command', :required, "Subcommand argument". This way, if the user omits the required argument, they should be shown an error message and the help. It also includes the argument name in the usage string, too.

I'd be up for enhancing the behavior around missing required args if the current behavior isn't quite right for you. A bit unsure about a special purpose help_if.

[dennisjbell]

Dave,

Sorry for waiting so long to get back to you, but I've been busy building some extensions to methadone for your consideration. These changes were developed as part of a real (but unfortunately closed-source) application, and have been proven in a real-world usage. These changes include:

• Options that can require other options be in use, or be mutually exclusive to another option
• Argument filtering
• "Smart" argument allocation - ensuring needy args get their minimal values before the first greedy argument gets the rest.
• No longer gobbles up unused ARGV values
• Added :terse and :basic argument to the version command as shorthand for providing just the number, or compact => true format you provided in 1.3 respectively.

--- and the big one ---

Subcommand support!

The reason I prefer having subcommands in Methadone over libraries like Thor, GLI, etc... is because I was able to construct a subcommand system that didn't require all the subcommands in a single file. The minimal amount of work I had to do to support subcommands modularly in Methadone was due to exactly what drew me to Methadone in the first place: a tight DSL that stays out of your way. (okay, there was a lot of changes, but most of that was just to get the help to display correctly -- having the subcommands work was trivial)

There is even an option in the methadone executable to build a base structure that gives you a layer of subcommands out of the box.

The code is well testing (97.1% coverage - most of the missing is due to the existing missing test for both env and rc file, plus the JRuby workarounds), and is nearly backwards compatible with 1.3 -- the only incompatibility is the ARGV changes, which is documented in the code as something you wanted to change. For this reason, I have labeled these changes as v2.0 on my fork -- please check it out at http://github.com/dennisjbell/methadone.

Thanks again for providing such a great foundation for building these features onto, and please consider these changes for your official version.

Sincerely, Dennis J. Bell

[davetron5000]

Hey, was out of town last week so just now looked this over. This is a pretty large change to take in. Based on just your comments, some of this would be great to have, although I have reservations about subcommands. Methadone was never intended to have that - it was only ever intended to be a simple CLI parser that improved on OptionParser's UI.

Further, adding subcommands brings up a ton of design problems that are mostly solved in GLI, such as sub-subcommands, intermixing of options, namespacing of options per subcommand, generating appropriate help output, defaulting subcommands, pre, post, and around filters, etc.

That being said, it's easier to talk about code than ideas.

I know it's probably a huge pain, but is there any way you can do a PR for the stuff that's not related to subcommand separate from the other stuff? It'll be way easier to examine and merge individual features than a whole bunch of new stuff at once…

[dennisjbell]

Dave,

I was on vacation last week, so also just getting to this now. I will definitely chunk out each atomic change into individual change requests, but it'll take some time :)

As for the subcommands, you are absolutely right in having to deal with all those issues, but the good news is I already did :) There are a few edge cases that make it not the ideal choice, but I would say that for 95% of people who want a simple modular subcommand system based on OptionParser, this will work well for them. But like you said, its easier to speak code, so I'll make those individual pull requests and submit them.

Cheers, -Dennis

[jamonholmgren]

If this goes beyond the scope of @davetron5000 's intentions for methadone, perhaps @dennisjbell would want to fork into a close cousin gem. I'd be interested in his implementation.

I found (perhaps through my own unfamiliarity) GLI to be a bit clunky to use. Methadone is super clean and lightweight and allows me to build what I want quickly.

[davetron5000]

This is super old, so closing. Still interested in some of the ideas in here, but will be easier to digest as small single-purpose changes.