You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
Dependency management.
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.
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.
The text was updated successfully, but these errors were encountered: