Add a Krane CLI with one command

[dturn]

What are you trying to accomplish with this PR?

Start down the road of adding a new CLI Krane. Our first step is adding krane version

See #256 for lots of details

How is this accomplished?
We've picked Thor to help make the cli as easy as possible. We've picked version to be the first command because it's just about trivial.

What could go wrong?
Its new code, so the only real issue is if the dependency causes people headaches.

CLI

➜  kubernetes-deploy git:(cli) ✗ be krane version         
[INFO][2019-08-14 11:06:56 -0700]	krane 0.26.7

➜  kubernetes-deploy git:(cli) ✗ be exe/krane  
Krane commands:
  krane help [COMMAND]  # Describe available commands or one specific command
  krane version         # Prints the version

➜  kubernetes-deploy git:(cli) ✗ be exe/krane version
[INFO][2019-08-13 16:43:39 -0700]	krane 0.26.7

➜  kubernetes-deploy git:(cli) ✗ be exe/krane version -v
ERROR: "krane version" was called with arguments ["-v"]
Usage: "krane version"

A fun question here is what exactly should the output be. I looked at kubectl, ruby, node, bash, and grep and each of these prints something different. Most are of the form program_name version_string. So that's what I went for.

[timothysmith0609]

I just need some clarification on the __FILE__ == $PROGRAM_NAME logic in exe/krane since it wasn't quite working as I would have expected.

[timothysmith0609]

Oops, didn't notice the failed CI before I 👍 but it's just a simple rubocop fix

Changes since I approved, going to start review over

[KnVerey]

I had a look at this yesterday and chatted with Danny. Here's a quick summary of my thoughts:

• I'm not a big fan of concerns, especially when they aren't being introduced to allow code reuse. In this case we're basically just using them to hide the code in another file. Let's make proper objects instead if we want to separate pieces of the code. I played around a bit, and this is my suggestion for an alternative: cli...knverey_cli (I'm not suggesting adding the deploy task in the same PR btw--just trying to get a feel for how something larger would look).
• I noticed while playing around with the branch that Thor automatically introduces two versions for boolean arguments, e.g. if you add --prune you also get --no-prune. That's not according to plan, but I'm fine with it.
• I also noticed that -f path/to/file -f path/to/other ends up with just path/to/other in the filename option. Maybe I'm doing something wrong, but that could be a problem. Let's confirm whether this works before merging anything with Thor. If it doesn't, you'll need to make a call on whether that's a dealbreaker (or maybe it could be PR'd upstream?).
• With a single CLI, we're always immediately loading all of our code, and that is visibly slow. Especially when all you're trying to do is print the help for a command. We should make sure the way we structure our code leaves us options for speeding this up. The obvious/easy/sketchy way would be to move the actual requires right into the command-invoking methods (or the thing they call). Maybe there's a better way though.
• Danny and I talked about having a blackbox test for each command that invokes the actual executable and basically just checks exit codes.
• Seeing an instance_variable_set anywhere is always a red flag for me (ivars are very internal details of a class!), but it is true that we have no way to inject a logger in this case. In theory the CLI classes themselves should not need to use our fancy logger though. Most of the time they shouldn't be printing anything at all themselves (version may be the one exception). Since these classes are getting their own small test suite, I'd suggest considering using the standard capture_io methods and running that suite in serial (those methods aren't threadsafe IIIRC). Here's an example that wraps capture_io to continue to provide the PRINT_LOGS option and expose the logs to helpers.

[timothysmith0609]

Overall this makes sense to me. I imagine we'll learn more as we start adding more commands, but this seems like a proper start. Just a few small outstanding questions before I ✅

[dturn]

This is a partial optimization to make loading time faster. If we require kubernetes-deploy it takes about 0.8 seconds to print the krane help. As is about 0.4 and if we require nothing 0.3. I feel like this strikes a good balance between not feeling to slugish to print help but not having to cherry pick exactly what we want when want it.

[dturn]

This is ready for 👀 though I don't want to merge it till after the -f flag PR. I played with what it might look like to add the --check flag in e6306af and feel good that there is a reasonable way forward for more than just trivial commands. @KnVerey took a stab at deploy in cli...knverey_cli and this pr took some but not all of the ideas.

[RyanBrushett]

Looks good to me

[dirceu]

Looks good to me!

[timothysmith0609]