Cli

Right, so you’ve built this magnificent CLI tool. It slices, it dices, it automates your most tedious tasks. But it’s sitting there on your machine like a fancy sports car in a private garage. What good is that? We need to get it into the hands of users, or at the very least, onto your other machines without a bunch of copy-paste nonsense. This is where go install shines. It’s arguably the single best feature of the Go toolchain for CLI developers. Forget tarballs, .deb files, or Homebrew taps for a moment (we’ll get to those later). For pure, unadulterated simplicity, go install is your best friend.

Right, so you’ve built a CLI tool. It’s a beautiful, gleaming piece of engineering. It has flags, subcommands, and it prints helpful messages. But you know what separates the tools you use from the tools you tolerate? A complete lack of friction. Every time a user has to hit TAB and nothing happens, a little part of their soul leaves their body. We’re not here to murder souls. We’re here to build muscle memory. That’s where shell completions come in, and cobra makes generating them almost criminally easy.

Right, so you’ve got your basic CLI tool working with some flags. Good for you. But now you’re thinking, “What if I want a flag that’s available to every single command and subcommand in my entire application?” Welcome to the world of persistent flags. This is where you stop just hanging pictures on the walls and start messing with the foundation and wiring of the house. The core idea is simple: a persistent flag is a flag that gets attached not just to the command you define it on, but to that command and every single one of its children. It’s inheritance, but for flags. This is perfect for global configuration settings—things like verbosity levels, configuration file paths, API endpoints, or authentication tokens. You don’t want to copy-paste the --config flag definition into every subcommand; that’s a recipe for madness and typos. You define it once on the root command, and boom, it’s everywhere.

Right, so you’ve graduated from the simple, idyllic life of flag and you’re ready to build a proper CLI tool, the kind that has commands, subcommands, and help text that doesn’t look like it was generated by a depressed robot. Welcome to cobra. It’s the library behind kubectl, docker, git, and pretty much every other CLI tool that makes you feel simultaneously powerful and slightly intimidated. Think of cobra not as a library, but as a very opinionated framework for organizing your CLI. A cobra.Command is the core building block, and it can be a root command (myapp), a subcommand (myapp create), or even a sub-subcommand (myapp create user). Each command can have its own flags, its own arguments, and its own logic. It’s a beautiful hierarchy, and it forces you to structure your application logically.

Look, I love the standard library’s flag package. It’s like a trusty old pocket knife: simple, reliable, and gets the job done for small tasks. But when you’re building a CLI that needs more than a single command—think git with its commit, push, pull—you’ll quickly find yourself trying to build a skyscraper with that pocket knife. You could do it, but you’d be welding with a butane lighter and it would be a nightmare.

Right, so you’ve built a simple CLI tool with a single purpose. It’s a beautiful, focused little thing. But then ambition strikes. You need your tool to create, list, and destroy things. You’ve outgrown a single set of flags. You need subcommands. And with subcommands, you need a way to have flags that are specific to just that subcommand. This is where flag.FlagSet struts onto the stage, looking a bit like a classic action hero who gets the job done with minimal fuss.

Right, so you want to build a command-line tool. Not a script you’ll forget about in a week, but a proper tool. The kind you go install and it feels like a real part of your system. We’re going to start with the absolute basics, the thing that’s been in Go since the beginning: the flag package. It’s the reliable, no-frills pickup truck of CLI parsing. It won’t win any beauty contests, but it’ll always get the job done.

Right, let’s get your tools sharpened. Setting up the AWS CLI is like getting a master key to the entire AWS kingdom. It’s the no-nonsense, text-based way to tell AWS what to do, and it doesn’t care if you’re in a GUI mood or not. We’re going to set it up properly so it doesn’t come back to bite you later. First, the installation. You’re not downloading some sketchy .exe from a random website. You’ll use pip, Python’s package manager. Yes, it’s written in Python. No, you don’t need to know Python. The irony is not lost on me.

Alright, let’s get your Python environment ready to boss AWS around. We’re going to talk about boto3, which is the official AWS SDK for Python. It’s the tool you’ll use to make AWS do your bidding programmatically. Forget the web console; you’re a programmer now. The goal is to write code that creates, destroys, and manages infrastructure. It’s like playing god, but with more error handling. First things first, get it installed. It’s not in the standard library, so pip is your friend.

Right, let’s talk about aws configure sso. This is the command that saves you from the dark ages of managing IAM user access keys, which are basically a permanent security liability you have to stash somewhere safe. With AWS SSO, you log in once through a pretty portal, get temporary, scoped-down credentials, and the CLI handles the rest. It’s a vastly more secure and manageable way to do things. The first time you run it, it feels a bit like magic. The second time, you’ll wonder why all cloud auth isn’t this (relatively) sane.

Right, let’s talk about the part of this process that everyone loves to hate: environment variables. We’re going to set them up so you don’t have to type your credentials every single time you want to list an S3 bucket, which is, I assure you, a fate worse than death. Think of environment variables as the sticky notes you leave for your computer. “Hey computer, here’s my secret key. Don’t show it to anyone, and use it when I ask you to do AWS stuff.” It’s a simple, effective, and tragically easy-to-mess-up system.

Right, let’s talk about the single most important tool for not accidentally deploying your resume to your production environment: named profiles. You’ve probably already used the default profile. You ran aws configure, shoved in your keys, and off you went. That’s fine for a single account, like your personal sandbox. But the moment you have more than one AWS account (and you will, because this is AWS and they give them out like candy), using the default profile is a one-way ticket to “oh god why is my production database in us-east-1 now?”

Right, let’s get you set up so you can actually do things with AWS instead of just staring at the login page. This is where we move from being a tourist to a resident. The CLI and SDKs are your primary tools, and they all have one thing in common: they need to know who you are. They do this using credentials. Let’s demystify how you give them those credentials without accidentally uploading your secret access key to a public GitHub repo (a classic rookie move, we’ve all had that heart-stopping moment).

Alright, let’s get you set up with the modern toolbelt. The AWS CLI v2 is a massive improvement over its predecessor—faster, handles IAM roles better, and doesn’t require a separate Python installation. We’re going to do this the right way, which means avoiding the OS package managers (apt, yum, brew) like the plague for this particular install. Their packages are often horrifically out of date, and wrestling with a three-year-old CLI version is a special kind of hell I won’t subject you to. We’re going straight to the source.

Right, let’s talk about not hating your life when you have to type kubectl for the eightieth time today. The Kubernetes API is a marvel of modern engineering; the kubectl command is a marvel of how many characters I’m willing to type before I start considering a career in forestry. We’re going to fix that. This isn’t about cute shortcuts; it’s about professional-grade tool sharpening. Your fingers are tired: The case for aliases First order of business: stop typing kubectl. You don’t need to. Your shell has this wonderful concept of an alias, which is essentially a text macro for the terminally lazy (a group I proudly lead).

Right, so you’ve mastered the basic krab-ing (kubectl get), the art of the describe, and you can exec into a Pod in your sleep. Welcome to the big leagues. Now it’s time to talk about how to make this Swiss Army knife of a tool even more powerful. Because let’s be honest, while kubectl is brilliant, it’s also a bit… minimalistic by design. The creators wisely decided not to cram every single niche feature imaginable into the core tool. Instead, they gave us a plugin system, and the community—in its infinite, beautiful wisdom—built krew to manage it. Think of krew as Homebrew or apt-get, but specifically for extending your kubectl command.

Right, let’s settle this. You’re going to hear a lot of dogma about Kubernetes: “Thou shalt only use declarative YAML!” It’s a nice ideal, but the real world is messy. You’re not a bad person for running an imperative command. The trick is knowing when to break the rules. Think of it like this: imperative is for a quick chat, declarative is for a binding contract. The Quick and Dirty: Imperative Commands Imperative commands are you telling the API server exactly what to do, right now. Create this! Delete that! They’re the equivalent of shouting orders into a walkie-talkie. Fantastic for exploration, quick fixes, and one-off tasks where you just need to get something done.

Right, let’s talk about making kubectl actually tell you what you want to know. By default, its output is polite, minimal, and often utterly useless. It’s like asking a concierge for directions and getting a single street name. The -o (or --output) flag is your way of saying, “No, seriously, I need the map, the traffic report, and the historical significance of the building on the corner.” We’re going to move from just getting a little more info to taking full, programmatic control. Strap in.

Alright, let’s get our hands dirty. Forget the theory for a moment; this is where you actually do things to your cluster. These six commands are the core of your daily kubectl life. Master them, and you’ll go from fumbling in the dark to having a firm, confident grip on your system. They are your primary interface for observing, modifying, and troubleshooting. The get Command: Your Cluster’s Dashboard Think of kubectl get as your ls or dir for the Kubernetes world. It’s your go-to for listing resources and getting a high-level, summarized view of what’s going on. Bored of typing kubectl get pods every five seconds? You should be. Let’s level up.

Right, let’s talk about your kubeconfig file. This is the single most important file on your local machine when you’re working with Kubernetes. It’s the master keyring, the backstage pass, the digital diplomat that tells kubectl exactly who you are, where you want to go, and how to prove you’re allowed to be there. If kubectl is your spaceship, this is the navigation computer. And like any good navigation computer, it can be configured to have multiple destinations.

Alright, let’s get you set up with kubectl, your new best friend and primary conduit for yelling at your Kubernetes cluster. Think of it as the remote control for a ridiculously complex entertainment system that’s also on fire. You don’t need to be on a cluster to install it, so we can do this right now and get you prepped for action. First thing’s first: you need the binary on your machine. The method matters because you want a version that’s compatible with your cluster. The general rule of thumb is to stay within one minor version of your cluster’s API server. A kubectl that’s too old or too new might lack the necessary commands or, worse, subtly break things. Trust me, “subtly break things” is the worst kind of break.

Right, so you’ve built this beautiful, clever CLI tool. It has more bells and whistles than a one-man band. Now comes the fun part: proving it actually works and won’t embarrass you the moment someone uses it in a way you didn’t anticipate. Testing. It’s the difference between a nifty script and a professional tool. Let’s get into the trenches. Mocking User Input and Arguments The core challenge of testing a CLI is that its primary input—command-line arguments—is handled by the framework (argparse, click, etc.) before your code ever gets to see it. You’re not testing the framework (it’s already tested), you’re testing how your code behaves once the framework has handed you the parsed arguments.

Right, so you’ve built this beautiful, powerful CLI script. It’s a masterpiece of argument parsing, a symphony of sub-commands, and it works flawlessly when you run it from your project directory with python -m my_awesome_cli. But you can’t very well tell your users, “Hey, just clone my repo, navigate into it, and run it with the Python module syntax!” That’s like selling a car but telling the new owner they have to carry the factory around with them to start it. We need to make this thing a first-class citizen on the system PATH. We do that by packaging it and creating console script entry points.

Right, so you’ve built a CLI. It’s got flags, it’s got options, it’s got --help text that would make a technical writer weep with joy. But it’s missing something. It’s… polite. It waits for you to tell it exactly what to do. What if you want a conversation? What if you want an application that prompts the user for input, offers choices, validates on the fly, and maybe even has some snazzy syntax highlighting? You don’t want a patient butler; you want a brilliant co-pilot.

Now, let’s be honest: your command-line tool could be a masterpiece of algorithmic efficiency, but if its output looks like a teletype from the 1970s, people will assume it is from the 1970s. We’ve spent all this time crafting a beautiful, intuitive interface for the user’s input; it’s borderline criminal to neglect their output. This is where rich saunters in, adjusts its cufflinks, and transforms your CLI from a greyscale terminal to a high-resolution console.

Right, so you’ve wrestled with argparse and maybe even flirted with click. You appreciate their power but are tired of the boilerplate, the decorator soup, or the sheer number of classes you have to instantiate just to ask for a username. Enter typer. This library is the brilliant, type-obsessed friend who looks at your function signatures and says, “Say no more, I got this.” It builds on click but uses Python’s type hints to do almost all the heavy lifting for you. The result is a CLI that feels almost magical, where you’re mostly just writing a normal Python function and getting a full-fledged command-line interface for free.

Right, so you’ve graduated from argparse. It’s a solid foundation, but you’re probably feeling the friction. Your script is starting to look like a Rube Goldberg machine of add_argument calls, and adding a second command feels like trying to build a second house on the same foundation. Welcome to click. It’s the library that looks at argparse and says, “What if we did that, but with decorators and actual, sensible organization?”

Right, let’s talk about argparse. It’s the old, reliable, slightly grumpy grandparent of Python CLI libraries. It’s built into the standard library, which means you don’t have to install a thing, and it’s powerful enough for about 90% of the command-line interfaces you’ll ever need to build. It’s not the most glamorous, and it can get a bit verbose, but it gets the job done with a kind of no-nonsense solidity. Think of it as the trusty socket wrench set in your toolbox—it might not be laser-calibrated, but it’ll tighten any bolt you throw at it.