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
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, systemtype: getversion: 0.14.10# os is an enum should be one of: linux, macos, windowsos: linux# arch is an enum should be one of: amd64, arm64, armv7arch: 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
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.
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.
Add a new feature where a user can provide a list of dependencies in a form of a config file like
arkadefile.json
orarkadefile.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:
To make this feature as polished as possible I think we need the following steps:
file install
this by default should look for anarkadefile.json
orarkadefile.yaml
in the$HOME/.arkade
folderfile 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(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 thearkade 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)
Context
In the realworld there are several usecases for this feature:
arcade file install
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
PS.: Ofc I'm willing to implement and maintain this feature in the longterm too, including documentation and reviews for related PRs too.
The text was updated successfully, but these errors were encountered: