Feature request: add support for auto installing cli and system tools via Arkadefile

Shikachuu commented 2 weeks ago

Add a new feature where a user can provide a list of dependencies in a form of a config file like arkadefile.json or arkadefile.yaml.

The goal of this feature to give users the ability do declaratively define their arkade "dependencies" and play nicer with dotfiles and declarative system configurations.

The shape of this file should be an array like in case of the arkade-get action.

So something like:

# name should be either a valid name for get or system
- name: faas-cli
# type is an enum in this case, could be one of: get, system
  type: get
  version: 0.14.10
# os is an enum should be one of: linux, macos, windows
  os: linux
# arch is an enum should be one of: amd64, arm64, armv7
  arch: amd64
# when we ommit the version key it should be considered as latest
# when we ommit the os and arch keys we should use the current default
# when we ommit the type key it should be considered as get
- name: kubectl

To make this feature as polished as possible I think we need the following steps:

agree on a common json/yaml schema
provide a schema descriptor with proper documentations (over time we should publish this on schemastore.org for a really nice IDE experience)
create a command that can read and install from this file format, imho this should be fine: file install this by default should look for an arkadefile.json or arkadefile.yaml in the $HOME/.arkade folder
create a command to generate an arakdefile imho this should be fine: file generate which has two flags --output | -o where the user can give a custom path and --format | -f where the user can specify the format (either json or yaml ofc) by default this command just prints the file content to stdout
create a command that can lint a given arkadefile (validate tools, keys and general schema)

(A LOT of inspiration for this feature comes from homebrew-bundle, however since we don't have any legacy ruby baggage I think the arkade implementation could be a lot better)

Expected Behaviour

When I place an arakdefile.json or arkadefile.yaml to my ~/.arkade folder or provide it with the --file | -f flag to the arkade file install command it should install the list of tools.

Current Behaviour

Not implemented

Possible Solution

To implement how it described above.

Steps to Reproduce (for bugs)

Not a bug

Context

In the realworld there are several usecases for this feature:

when you have an immutable server os like coreos and in your coreos config you provide this file and run arcade file install
when you have dotfiles in your machine where you have a single install command, where you want to install all the tools to your new and shinny machine

If requesting a CLI for "arkade get"

How many downloads does this tool have? Check at:

https://somsubhra.github.io/github-release-stats/

If approved, are you willing to submit a pull request for this?

Your Environment

What Kubernetes distribution are you using?

Client Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.2", GitCommit:"f66044f4361b9f1f96f0053dd46cb7dce5e990a8", GitTreeState:"clean", BuildDate:"2022-06-15T14:22:29Z", GoVersion:"go1.18.3", Compiler:"gc", Platform:"linux/amd64"}
Kustomize Version: v4.5.4

Operating System and version (e.g. Linux, Windows, MacOS):

NAME="Fedora Linux"
VERSION="40 (Workstation Edition)"
ID=fedora
VERSION_ID=40
VERSION_CODENAME=""
PLATFORM_ID="platform:f40"
PRETTY_NAME="Fedora Linux 40 (Workstation Edition)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:40"
DEFAULT_HOSTNAME="fedora"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f40/system-administrators-guide/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=40
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=40
SUPPORT_END=2025-05-13
VARIANT="Workstation Edition"
VARIANT_ID=workstation

What arkade version is this?

Version: 0.10.15
Git Commit: d6ed17ccca84f8db93693f541894c675eef21f16

PS.: Ofc I'm willing to implement and maintain this feature in the longterm too, including documentation and reviews for related PRs too.

rgee0 commented 2 weeks ago

I'm not clear on what this would provide above and beyond a set of individual calls to arkade, which, if scripted, would arguably be more accessible to a user than mastering yet another yaml file. I have the faasd install script in mind a little here where an installation (dependency) order is in effect. I see dependencies mentioned but no description on how these would be handled.

If this does move forward then type should be in terms of tool and app rather than the CLI verbiage.

Shikachuu commented 2 weeks ago

Since arkade tools are mostly static binaries there is no need for actual dependencies, however the order of the tools should decide this like in the case of brewfiles. (I have a brew mas and immidetly after that a mas install <app id> and it works just fine.)

I accept your opinion, however I find the comparison between a yaml array with an object of 4 fields (3 of them is optional) and writing shell scripts with the reason being "mastering yet another yaml file" is a bit of a stretch. If you ever wrote at least 1 shell script to do some part of this proposal (which I assume both you, Alex and I did) then I think this feature could be implemented to eliminate this kind of glue code.

Imho this is way more readable than using shell scripts:

- name: kubectl
- name: gh
- name: caddy

In the description there is a command for generating this kind of yamls/jsons too, to make it simpler.

Also it just doesn't make sense to install apps with this feature, because there will be almost no difference between this function or using helm.

This feature meant to "compete" in a sense with the above linked brew bundle.

alexellis / arkade