Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Shikachuu opened this issue Jun 16, 2024 · 2 comments

Comments

@Shikachuu
Copy link
Contributor

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)

  1. 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
Copy link
Contributor

rgee0 commented Jun 17, 2024

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
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants