How To Create A "Proper" CLI With Shell And Charm Gum

[@DevOpsToolkit]

What do you think about Charm Gum? Is it as glamorous as it says it is?

[@adrien-barret]

really cool for fast result, but bubbletea in go make a nicer result ;p

[@DevOpsToolkit]

Oh yeah. The "real" CLIs should be in Go with Charm libraries.

[@testep02]

Man, I have worked with people that wrote entire CLI tools using nothing but bash. And I can tell you, that's the most painful thing I have ever had to work with and maintain. I get where these tools come from. I get the use case they attempt to cover. However, I would caution that using these tools to create a CLI should be a last resort and should ONLY be used to perform extremely simple tasks. No one wants to maintain a mountain of bash scripts, trying to make sure the ENV is setup to execute whatever these scripts do, etc. A proper programming language should ALWAYS be encouraged when creating tools that will need to be maintained, will be distributed to others to run locally, etc.

[@DevOpsToolkit]

I agree, but with a note. What you're saying is 100% valid when talking about more complex scenarios. There are cases, though, when you do have a relatively simple Shell script, yet you still need to ask for user input, show progress, make it nicer, etc. To me, Charm Gum in a good solution when it's simple, yet requires some kind of user interaction.

[@testep02]

@@DevOpsToolkit Yep, that's exactly the sentiment I was hinting at in my comment :) Great videos, BTW. I've been a DevOps professional for 8 years now and I love your content.

[@biigsmokee]

Freezing cold, insanely flaccid take. CLIs are more efficient than a gui almost every time

[@simianpiate]

Perfect timing of this video! I was researching some tools to make our demo deployments easier and more interactive. This definitely fits in with my vision. Thanks!

[@kazwalker764]

I just built a Helm wrapper with Gum on Friday (for work, not open source). It lists the kubectl context and get the user to select one, it's super handy.

[@charmcli]

Thanks for the feature!!

[@nebroTtfeoH]

Well deserved, your work is awesome!

[@samuelbanya]

Very cool video. Thanks for this dude, I could totally use some of this for personal or work based workflows.

[@valour.se47]

This is freaking great tool, this tool can be a gateway to my other shell scripts :D

[@Protagonist369]

PowerShell has a nice support for making scripts act like CLI, hence you can write pretty huge modules in powershell after all, it's a general purpose language too. Because of this, although I don't like PowerShell, I would prefer it to bash anytime in any environment

[@DevOpsToolkit]

I'm not fond of bash either but it is everywhere (including windows with wsl) while power shell is only on windows by default. I know thst one can, for example, install it on Mac but i don't think anyone does.

[@Protagonist369]

@@DevOpsToolkit yeah, powershell needs to be installed on other systems, although I was surprised to know that it's used extensively Linuxes nowadays. After several years of working with it I didn't like developing something big with it at all, but having this option of writing a quick user-friendly CLI in a general purpose shell-like language was nice

[@arieheinrich3457]

Awesome ! you should combine Gum with Just (ask Darin to show you, he has a jenkins with Just vid about it). Im going to implement this internally for my teams !

[@Alexander-yu9uy]

Looks very good! But, this means that my shell CLIs are going to be dependant on gum installed on a user machine?

[@DevOpsToolkit]

That's indeed the major downside and I don't think there's a way around it since it's just a Shell script that executes commands. The same is true if, for example, the script uses `kubectl`, `helm`, or any other command. Now, what you can do is add the installation of Charm Gum at the begining of the script (before you start using the commands).

[@scottamolinari]

Once more, great video. Gum looks pretty cool for automating the CLIs of other tools. Which brings me to a tangential nooby question about offering/ using CLIs in pods/ containers in k8s. Is it possible, and if yes how, to offer access to a CLI's commands, but not the underlying commands of the tools being used? As a use case, imagine offering developers (external to the cluster i.e. tenants/ guests) remote dev environments (namespaced of course). They can run their app (which will also be linted for bad acting code, as part of running it) and they should have access to a CLI, which helps run the app and do other dev chores. The devs should only have access to the CLI commands and not any commands of the underlying tools, like git or any Linux commands. This is one challenge I'm unsure of with my lack of experience . Obviously the plan is to only allow coding in a non-production cluster to guarantee that production code doesn't get bamboozled. But, I'm still wondering about the security of these dev environments. Is this "lockout" of lower level commands and yet have access to run the CLI that runs these same commands even possible? Scott

[@DevOpsToolkit]

Ideally, your images would be based on scratch and containers created from them would not be able to do anything but run the app itself. Now, if you need to enter such containers and have additional tools, you can attach debug containers to that pod. It is a feature introduced not long ago.

[@scottamolinari]

@@DevOpsToolkit Thanks for the reply. The tenant would be inside the container working in a remote dev environment (with Coder). So, I'd need git and node (it's a node platform) as a minimum. What I don't want is the tenant running git commands on their own. They can only run the CLI that would also be installed in the container for them. Now I'm wondering if I could avoid even having a CLI. Just run things over an API. Hmm..... 🤔. Thing is, Coder's code-server also allows for a terminal connection. Though, the dev environment can be started as a particular linux user, so she can be stripped of any access to underlying linux commands theoretically. I guess I'll just have to experiment. 😁

[@DevOpsToolkit]

I'm not sure how Coder works so I cannot answer specifically for it. What I can say is that you either need Git CLI called from the CLI you're creating (and potentially accessible) or you need to do everything through API calls (in which case you do not need `git` CLI).

[@1879heikkisorsa]

I want to build a tooling CLI for my team abd one of the features I find crucial is autocomplete. But I don't see a way to do this with gum. Is there an easy way to add autocomplete to a CLI?

[@DevOpsToolkit]

That's not available in Gum. You'd probably need to either find a shell command that does that (if you want to add it to a script) or a library for your favorite language you'd use to create the CLI.

[@CyberSamuraiX]

From an end-user perspective, they would need to have gum installed on their system in order for you script to work then?

[@DevOpsToolkit]

Yes. They would have to have Gum installed or the script they're running would have to install it.

[@plixplux]

Don't get me wrong - this looks fantastic. But isn't it more a wizard-creator rather than a CLI-creator? Maybe I've misinterpreted the term, but when I think "CLI", I think tools such kubectl, rclone, argocd and so on. I think I'll take a look at Gum's page and see if I've misunderstood.

[@DevOpsToolkit]

It is kind of a wizard creator in terms of having different means to capture user input, plus a few other things.

[@SiCrip09]

Can you also combine GO CLI with Cobra and charm gum?

[@DevOpsToolkit]

You can. If you use it in Go, it's just a few libraries that you import and you can combine them with anything else you do in Go.

[@lattakia3812]

I write my CLI tool in C

[@M3MYS3LF1979]

I see you woke up and chose violence

[@JohnKevinSoriano]

🎉