piotrmurach/tty-option

A bit confused about the usecase for CLI gems

progapandist opened this issue Β· 3 comments

Do I understand correctly that this gem is not a replacement for Thor or dry-cli? According to the README, the mixin makes it easy to configure a single command, but if I want my CLI tool to have different commands β€” what would be the recommended course of action?

I see no easy way to create multiple "commands", each with its own description, place in a general help message, and arguments/flags/keywords.

So if I want my gem to be able to do:

my_gem walk --the --walk
my_gem talk --the --talk 

my_gem --help
# talk ...
# walk ...

...how can tty-option help me? Or am I required to take care of "top level" switching on STDIN to determine which command to dispatch and then handle the command with tty-option? Seems like a barrier for entry to me, if that's the case, as I would still have to opt for something like dry-rb to parse the "top level"

Hope you can clear that up for me πŸ€” Anyway, amazing work on this! πŸš€

Hi Andrey πŸ‘‹

Thanks for trying tty-option.

In short, you're right, the tty-option is for declaring a single command and not a replacement for Thor. Not by itself at least. However, I needed a far more powerful option parser that can be easily plugged into any class/framework.

I have some good news. Recently I started work on tty-runner which is a routing tree for command-line applications (not released yet). This will serve as a replacement for Thor. It's not finished yet but will be soon. You can easily plug in tty-option commands (see example). I think this is a perfect opportunity for you to try it out and contribute! Let me know what you think.

Certainly gonna give it a try. I have to admit I hate Thor. It’s just... not... good UX, no matter how you look at it. So doing the same Thor-free with your gems can be a fun adventure in a search for something new

I used thor initially for the tty but it was always a temporary solution. The tty-runner will replace it when it is ready. It has a different approach and separates commands from actual implementation. This is especially important in building large command-line apps with many subcommands.