Switch to Cling for parsing

[devnote-dev]

Hi Lucky team,

I've been working on a CLI library called Cling that allows you to design scalable and robust command line applications without having to deal with complicated macro logic, it's quite good if I do say so myself but I'll let you be the judges of that. It's currently used in phenopolis/thumbnailer and PteroPackages/Aerotitan for production, and I believe it will be a useful addition to Lucky CLI.

Advantages

• Highly configurable: the library is designed to be almost entirely modular, so you can configure it as much as you like
• Scalable: you can add, remove and refactor commands easily and with much almost no hassle
• Standardised: the library is based off the well-known Go library cobra which tightly follows the GNU convention for command line interfaces
• Spec compatible: you don't have to jump through hurdles to get good command specs, Cling supports them! See Cling's command specs for examples

You can view the full list of features in the README.

But Why Cling?

I believe that Cling fits Lucky's design: being able to create fast, scalable web applications that has a plethora of configurable options without being overly verbose or hard to navigate. With Cling, it's the same: being able to create fast, scalable command line applications with a plethora of configurable options while still being simple and easy to navigate. Often with command line libraries/frameworks, you have to write a lot of boilerplate, memorise lots of (sometimes unconventional) macro methods, define nested classes, and other tedious requirements – not with Cling. The library follows a consistent design, plus the benefits of being modular, and will ultimately improve your command line application experience; you just need to make the first step.

Conclusion

I hope I was able to convince you to use Cling for Lucky CLI, please let me know what you think and feel free to ask me anything. 😄

[jwoertink]

Hey! Thanks for the suggestion. Cling does look pretty interesting. The only thing though, is we actually have a policy to try and avoid pulling in shards from outside of the framework ecosystem, unless we know they are fully community maintained. The issue is, if you get too busy to work on Cling, and there's bugs that hold up Lucky in any way, then I become forced to fork it. We've had to do this with shell-table, cry, and teeplate for example.

Now, I have considered using a CLI tool outside of just the standard option parser, but my idea was actually to do a CLI UI interface more like bubbletea or gocui. Obviously this would also require me to pull in some extra shards (or build them myself which I don't want to do)... Is this something Cling would be able to do, or has planned?

[devnote-dev]

I completely understand, I've seen this happen a few times with other open source projects and know how much of a hassle it can be. With that being said, I'm fairly "new" to the Crystal community and have no plans to discontinue maintaining any of my shards if that's any consolation. 😅

I do have plans for something like Bubbletea (I'm familiar with it, great library) but not with Cling. I want to keep the command parsing/handling part of things for Cling and create another shard for CLI UI to maintain modularity.

[jwoertink]

Sweet! That's cool. Well, I'll definitely keep it on the table. It's been a bit lower on my priority, but when I circle back around to it, I'll play around and see how it is.