gruntwork-installer icon indicating copy to clipboard operation
gruntwork-installer copied to clipboard

Provide a simple way to upgrade the tools

Open ThierryAbalea opened this issue 7 years ago • 1 comments

As I understand, to upgrade a tool we need to re-run the same command than for the installation, replacing the version.

It will be good for the sake of simplicity and to avoid the rot of the tool versions, to have a way to upgrade easily the different tools.

It could be a command: gruntwork upgrade. It will require of course some metadata regarding the list of the tools installed.

Did you considered using existing package managers (brew, apt-get, ...) ? There are solving lots of problems than new coming packing managers will face sooner or later.

I understand than some of your tools are private. Brew seems to provide a way to support this.

ThierryAbalea avatar Jun 18 '17 17:06 ThierryAbalea

We do want a way to offer easy updating, although it's been a relatively minor concern, as 99% of gruntwork-install usage is in Packer templates and Dockerfiles, where you just build a new image from scratch every time anyway. That said, some of the major TODOs to figure out for the Gruntwork Installer are:

  1. Dependency management.
  2. Upgrade process.

We looked at many other alternative tools, including brew, apt-get, yum, nix, and so on (see motivation). None of them fit all of our requirements:

  • Cross-platform. The packaging system should work on most major Linux distributions. It should also work on OS X, as that's what many people use for development.
  • Simple package manager installation: We don't want a package manager that takes a dozen steps to install.
  • Simple client usage. The scripts and binaries we install are simple, so it shouldn't take a dozen steps to install one. Ideally, we can use a one-liner such as apt install -y install-consul, except it should work on all major Linux distributions.
  • Simple publish usage. We need a fast and reliable way to publish new versions of the scripts and binaries. Ideally, we'd avoid having to publish each update to multiple package repos (apt, yum, etc), especially if that requires any sort of manual approval (e.g. a PR for each new version).
  • Supports private repos. Most of our code is private, so we need some way to control who can access it.

Nix came the closest, but it's confusing to use and has very limited docs, especially regarding private repos. As a result, we built Gruntwork Installer, and will either continue to improve it, or perhaps find some other tool that fits all of our requirements.

brikis98 avatar Jun 18 '17 23:06 brikis98