command line interface

[tgross]

The Nomad team has a fork of this project (https://github.com/shoenig/hc-install) with the command line interface implemented (and Vault added). We use this to install Consul and Vault as part of CI (ex github/workflows/test-core.yaml#L148-L149). Rather than having to keep up with release API changes, we'd like to upstream our work.

Fixes #13

[radeksimko]

Thanks for the PR @tgross

I took the liberty and cherry-picked your commit adding Vault to main and added a test for the build (which tends to be most fragile of installation methods) bbc7232

Regarding the CLI, I have some thoughts on the UX - will review this 🔜 .

[radeksimko]

The library started out with a relatively flexible (Go) API and a minimal dependency tree, both of which is also what motivated https://github.com/hashicorp/hc-install#hc-install-is-not-a-package-manager and make it possible for e.g. Terraform SDK to use this without much cost. It would be great if we could keep it that way.

I'm happy with hc-install providing some minimal CLI interface, but I wouldn't want it to step into the area of https://github.com/gulducat/hashi-bin I think if we stick with the mentioned design guidelines, it should be possible and relatively easy to build tools such as hashi-bin/tfenv and any other similar ones top of this library by leveraging the Go API.

With all that in mind:

1. How would you feel about the UX being hc-install install <product> [-version=<VERSION>]?
   • This leaves room for -version-constraint or -build-rev should we need to implement it in the future.
   • This also leaves room for e.g. hc-install list-products should we need to implement it in the future.
   • We could treat hc-install install <product> as "install latest version of ". I'm not suggesting to do it now, but it just seems more natural to make a named flag optional than a positional argument.
2. How about we create the product.Product{} on-the-fly? Since we're limited to installing just from releases.hashicorp.com, we can technically support almost any product from there (any which is packaged as ZIP), as installation from there only requires Name and BinaryName, we don't need GetVersion() nor BuildInstructions

   hc-install/product/product.go

   Lines 10 to 24 in 2695df3

   	type Product struct {
   	// Name which identifies the product
   	// on releases.hashicorp.com and in Checkpoint
   	Name string
   	// BinaryName represents name of the unpacked binary to be executed or built
   	BinaryName BinaryNameFunc
   	// GetVersion represents how to obtain the version of the product
   	// reflecting any output or CLI flag differences
   	GetVersion func(ctx context.Context, execPath string) (*version.Version, error)
   	// BuildInstructions represents how to build the product "from scratch"
   	BuildInstructions *BuildInstructions
   	}

3. Would you mind making the installation path a flag? e.g. -path?
   • You can still pass -path=$GOBIN or -path=$GOPATH/bin downstream if you like.
   • This avoids setting any expectations on where the binary gets installed and avoids excuse for future PRs adding various other locations and us having to decide preferences between any of these and address other kinds of related problems, like where/whether does it need to be tracked and whether the CLI should also have uninstall or upgrade command. Generally avoids the scope-creep into a package manager territory.
   • Should this be a required flag? If not, what's the default?🤔 We could install by default into os.TempDir(), just like the Go API does, the only question is how do we communicate that binary path back.
     • We could make it the only output on STDOUT and send other log lines with progress etc. to STDERR?
     • We could just print it out along with some other human-friendly output and introduce -json flag for JSON output, so downstream can pipe it into jq?

---

I understand I'm suggesting some significant changes to your PR, but I hope the context and explanation above can help understand why.

Either way - thank you for kicking this off and raising the PR and thank you for the patience. Let me know what you think!

[shoenig]

This all sounds reasonable @radeksimko - but I am wondering about the default value for -path.

We could install by default into os.TempDir(), just like the Go API does

What is this referring to? I was basing the idea off of go install which installs into GOBIN or GOPATH/bin.

[kmoe]

Thanks for this!

Agree with @radeksimko's comments above. In particular regarding the default installation path, note that as per the README,

hc-install does not:
Determine suitable installation path based on target system. e.g. in /usr/bin or /usr/local/bin on Unix based system.

I think therefore the default path for downloaded binaries should be the current directory, the analogy being curl/wget rather than go install or apt-get.

While os.TempDir() (as in LatestVersion.Install() for example) is also a good option, it is less idiomatic for a CLI tool to output the path of a downloaded file. The hc-install CLI is intended for use in build scripting, in which the wget paradigm is common: the file is either downloaded into the current directory and then moved, or a path is supplied.

[radeksimko]

@kmoe I like that idea 👍🏻 and I like your analogy with curl/wget - that also avoids the need for communicating an unpredictable random temp dir path back. All the consumer needs to know is name of the binary, which it presumably already does, so we can avoid the complexity of a predictable strict output format.

@tgross How does that sound as a default option for -path?

What is this referring to? I was basing the idea off of go install which installs into GOBIN or GOPATH/bin.

I was just referring to the Go API of this library rather than go install, as Katy mentioned

hc-install/releases/latest_version.go

Line 82 in af09eee

dstDir, err = ioutil.TempDir("", dirName)

[tgross]

@tgross How does that sound as a default option for -path?

Works for me. I'll take a pass at updating this PR with your suggestions sometime in the next couple days probably.

[tgross]

I've updated this PR as follows:

• rebased on main to make it just the CLI changes.
• hc-install install is now a subcommand.
• The subcommand takes a required -version flag.
• The subcommand takes an optional -flag path, defaulting to installing in the current working directory.

@radeksimko I thought I understood this comment:

How about we create the product.Product{} on-the-fly?

But then when I went to look at it I don't think I understand what you're asking for here. 😊

[radeksimko]

Thanks for the updates @tgross

This is getting quite close to a merge-able state. I left some suggestions in-line.

[tgross]

@radeksimko I've updated the PR to resolve all the suggestions except for the question about whether --version should be required, which still seems open for discussion? I can squash/rebase this as needed as well too, just let me know.

[radeksimko]

Hey @tgross
Thanks for making these updates.

Aside from my in-line comments, this LGTM.

[tgross]

Resolved merge conflicts on the go.mod

[kmoe]

Looks good - thanks for doing this!

One bugfix then we can merge this. I'd like to add some e2e tests but that can be done in a subsequent PR.