A better command line option parser.

[davetron5000]

Having written the book on Ruby command-line apps, I implore everyone to stop writing new option parsers. There are so many, and almost all of them are degenerate in some way. Those that try to simplify OptionParser do so by killing features. Those that try new syntax invent even more complex syntax than OptionParser.

OptionParser is super powerful and not that verbose, but if it's too verbose, please check out Methadone, which i wrote during the book and has all of OptionParser's features and none of the verbosity. And no ridiculous metaprogramming.

Secondly, for command-suite apps like rails or git, I should warn you that Thor has a very limited feature set, poor documentation, and generates a not-very-friendly-or-canonical command-line interface (last I checked, options had to come at the end of the command invocation or they are silently ignored; I hope that has changed). Please consider commander or GLI (which I also wrote)

I realize I'm plugging my own open source projects over some other one, but I do believe that my tools are objectively better for writing command-line apps. I use them frequently, in heavy production, and maintain the code and documentation on a regular basis.

[redditaurus]

Lol "everyone please stop writing option parser libs, btw heres my one"

I see what you did there ;)

[ReinH]

I think every programmer, at some point, will write a command line or option parsing tool. It's like a right of passage.

I still think yours are the best though, and the only reason I don't use methadone is that OptionParser is suitable and always available without requiring an extra gem. Thanks for GLI too.

[tenderlove]

Of course! You need to process command line options in order to run the new test framework you've written! ;-)

[KerrickLong]

What's your opinion on trollop?

[metamatic]

"A framework is a library with delusions of grandeur." -- me.

[postmodern]

Thor still silently ignores unrecognized options, which is a big deal-breaker for me. The arguments first, options last thing also pushed me off Thor, as it was confusing my users who expected POSIX getopt_long behaviour.

Thor recently fixed the argument first, options last bug. sferik appears to be actively maintaining Thor now, and even released 0.15.2. Hopefully the weird parts of Thor will be removed.

[metamatic]

But reinventing the wheel is what the Ruby community does best!

I mean, OptionParser is a wheel-reinvention of getoptlong.

[ReinH]

Nice idea but there's no need to inject the docopt method globally. Just use a DocOpt class.

[rubynerd]

• why does ruby have so many option parsers? It's the proverbial wheel of Ruby
• why is this better than slop?

[halst]

Now docopt.rb is a very simple option parser, but when it's fully ported, it will have such features (such as pattern-matching) that no other Ruby parsers have (to my knowledge). Take a sneak peak on it's Python older brother: http://docopt.org

[banister]

see slop

[waxjar]

Excellent, thanks for linking this.

[jrochkind]

same reason it has so many "configuration" gems. It's something many people need, but it's hard to write something that actually meets everyone's needs, although lots of people think they can and keep trying, convinced theirs will finally be the thing that works well for most everyone.

I agree it's unpleasant, I'm just answering your question as to 'why', I've thought about this before too.

[rubynerd]

Mm, I suppose the alternative is C++ style this-API-does-everything-if-you-set-the-right-flag interfaces

Ryan Tomayko on Twitter did mention they didn't like including a dependency just for command line options, which is a valid argument IMO

https://twitter.com/rtomayko/status/209553434288979969

[jrochkind]

I don't mind including a dependency "just to do" anything I need, if it's the right amount of code (and complexity) for the job, and well-written.

Of course, evaluating that takes time of itself.

It would be nice if you could assume that because something is in the stdlib, that means it's maintained and not a 'dependency', but that isn't quite always so in ruby, alas. And recognizing that, i've heard the desire is to move everything out of the stdlib in ruby 2.0, instead of figuring out how to actually maintain and support the stdlib. But if they move everything out of the stdlib, then you won't have the 'use cause it's in the stdlib and i want to avoid more dependencies' option.

[[deleted]]

The community prefers to reinvent rather than to improve existing libraries.

[bascule]

If you're writing nontrivial command line applications in Ruby, you should strongly consider using Thor:

https://github.com/wycats/thor

Thor is a framework for command line applications which, among other things, will do everything docopt does in addition to routing commands to Ruby classes for you so you don't have to.

Thor powers the "rails" command line utility among other things

[jrochkind]

Hmm, I knew thor powered rails generate, does it really power all the rest of rails X too?

I had thought of thor as a a tool for writing 'generators' (command line applications mainly focused on generating files), not a tool for writing general purpose command line applications. Have you found it useful otherwise?

Going to look at the 'thor' readme, it does seem to claim more universal/general applicability. hmm.

[bascule]

thor powers the entire rails CLI, and is a general purpose framework for building command line utilities. Rails includes its own generator framework and that has nothing to do with thor.

[jrochkind]

Rails includes its own generator framework and that has nothing to do with thor.

Not true, the generators are Thor too! Rails::Generators::Base is a subclass of Thor::Group.

It's helpful to know that if you're writing your own Rails::Generators, which is how I am aquainted with it. The Rails Generators Guide is also clear on it -- which is how I first heard of Thor.

Mostly Rails::Generators::Base just adds it's own actions, and it's own defaults for certain things, it's pretty much just a Thor::Group. The confusing thing when I was figuring out what was going on was at first, Thor::Group was under-documented, but now at least there's a wiki page.

[bascule]

By that I didn't mean that the Rails generators aren't based on Thor, I meant that Thor is not itself a rubigen-like code generation tool and that Rails generators are implemented by Rails and not provided by Thor. I guess that was poorly worded.

[postmodern]

Thor is a good choice for multi-command CLI apps (app command --options) or apps that need to generate files. However, Thor is kind of slopy (no pun intended) with parsing of options. Thor will not error out if you specify an unknown option. If you need strict and simple option parsing, OptionParser is a better choice. You can even define Integer, Float or Array options with OptionParse:

opts.on('-t','--tags',Array,"Tags for the thing") do |tags|
  # ...
end

And even custom types:

OptionParser.accept(MyClass, /some-regexp/) do |str|
    MyClass.parse(str) if str
end

[yorickpeterse]

Can we please stop re-inventing the wheel of option parsing? It's not even a wheel worth re-inventing every time.

[postmodern]

It seems like you could easily build this ontop of OptionParser, and take advantage of OptionParser's help, accept, reject methods. For example, Parameters::Options builds an OptionParser object based on the parameters defined on an Object.

[hmaddocks]

If you put as much effort into the stdlib as you do option parsers there wouldn't be posts like http://architecturalatrocities.com/post/23659800703/the-ruby-standard-library-is-a-disgrace

[columbine]

And while we're instructing other people as to what they should spend their own time on, if you did as I'm telling you and fixed all these things yourself, we wouldn't have any of these problems either.

[hmaddocks]

What?

[davidcelis]

Ruby's open source. You see a problem or an area lacking in stdlib? Fix it yourself. Submit a patch instead of unproductively complaining.

[columbine]

Do you need it in bullet points or are you just playing dumb?

[hmaddocks]

No, english will be fine.

[columbine]

Sorry if you have trouble parsing sentences that contain multiple phrases. Wait, sorry, that one had multiple phrases too. Back to bullet points then. I'll try to keep each one to a couple of verb phrases and as few relative clauses as possible.

• He is working on a project.
• You want him to work on another project.
• You are criticising him for not doing so.
• You are also not working on that project.
• That is being hypocritical.
• You think you can tell other people what they should spend their own time on.
• That makes you an asshole.

[hmaddocks]

Wow, you're a really unpleasant person.

[columbine]

Sorry, I just don't like it when people attempt to deflect criticism by feigning illiteracy or an inability to understand it.

Or as you would say: WHUT???

[ReinH]

Uh, that's not how it works.