Consider migrating bash scripts to Go

[hasheddan]

Currently all of crossplane-cli is written in bash except for the trace command. In order to make the code more testable, easier to modify, and able to compiled into a single binary, it would be useful to migrate the existing bash scripts to Go.

[suskin]

I want to leave a little bit of counterargument here to help people think about this.

Some (not all) of the bash scripts are very simple, and are calling other commands. Bash tends to work very well for this, so it may make sense to consider using bash for those commands. For example, many of git's porcelain commands (random example) are written as shell scripts for this reason.

That said, other things that the cli is doing, such as interacting with kubernetes clusters and objects, are not necessarily convenient from bash, and could be a much better fit for Go.

Whoever's working on this will want to weigh the tradeoffs between bash and Go for each of the commands. If I were to make a suggestion, I'd say build and publish seem like they are the closest to being good for bash since they interact with make and don't do a whole lot, whereas install, uninstall, and list seem like they are more likely to be more maintainable in Go since they interact with kubernetes objects.

[hasheddan]

@suskin I am not sure that the bash scripts being simple make them a good practice. As you mention, they are simple because they are deferring to make and other commands. I am not suggesting that we rewrite these commands to call make from go, but rather that we rewrite them so they are not reliant on the presence of other commands on a local machine. In general, I think distributing a single binary, rather than a binary and a handful of bash scripts, is a better practice.

That being said, this issue was opened as an opportunity for a new contributor or someone with bandwidth to take ownership of this tool and drive more features and capabilities. I do agree that when porting existing bash functionality to go commands build and publish likely should not be the first priority. However, in the long run, I believe a well-tested, single binary tool will scale better and maintain higher quality.

As always, thank you for your insight here :) a healthy balance of "if it's not broken, don't fix it" and "let's optimize everything" usually results in a solid outcome 👍