a modular and extensible shell framework inspired by the natural composition of chitin — the material forming the shells of many organisms
The framework's taxonomy mirrors how chitin builds shells:
helper
: individual shell functionschain
: collections ofhelpers
focused on specific domains. Chains are composed of interlinked chitin molecules.fiber
: top-level modules grouped by domain. Fibers provide structure by linkingchains
together.module
: general term for forchains
andfibers
, used when something is applicable to either
chitin-core
├── chitin-dev [fiber]
│ ├── docker [chain]
│ │ ├── build_image() [helper]
│ │ ├── run_container() [helper]
│ ├── git [chain]
│ ├── clone_repo() [helper]
│ ├── commit_changes() [helper]
├── chitin-cloud [fiber]
├── aws [chain]
│ ├── launch_instance() [helper]
│ ├── list_buckets() [helper]
├── kubernetes [chain]
├── deploy_pod() [helper]
├── scale_deployment() [helper]
-
Clone this repository to your
project dir
(the directory where you usually rungit clone
) -
Add the following line to your profile (ie
.zshrc
or.bashrc
), substituting<project dir>
:source <project dir>/chitin/init.sh
-
Start a new shell session, and follow the instructions to configure
chitin
by runningchiConfigUserModify
Note: if you would prefer to not automatically load fibers (such as for performance reasons), set
CHI_AUTOINIT_DISABLED=true
, and use the commandchiShell
when you want to load them on-demand
The framework can be configured at three levels: user
, fiber
, and chain
.
*Dir
fields support path expansions:
~
: ->$HOME
localshare
->$HOME/.local/share
The user
configuration contains global settings, and allows you to set machine-specific overrides:
dotfilesDir
: directory where you store your dotfiles (absolute path)projectDir
: directory you clone git repositories to (absolute path)installToolDeps
: whether any missing tool dependencies should be automatically installed
Modify this config by running chiConfigUserModify
.
Both fiber
and chain
configurations support the following fields:
enabled
: whether this module should be loaded (default: true)tools
: allows you to declare and configure tools that modules can depend on- see Tool Configuration for details
toolDeps
: which tools this module depends on, and should not be loaded without
Tools can be declared in any module, and then referenced in the toolDeps
of that module or any depenendent ones, such as a child chain
or a dependent fiber
and its chains
.
Tools can be configured with:
- an install method (optional)
- a presence check
- required, unless the tool is set as
optional
.
- required, unless the tool is set as
- a version check (optional)
In addition, the following configuration options can be set:
optional
: whether this tool should be checked for presencepostInstall
: a command to be run after a successful install
Tools can be automatically installed if installToolDeps
is set, using the following install methods:
brew
: install with brew; all subfields are optionalname
: can be used to override the tool namecask
: indicates that the tool is abrew cask
tap
: set to the name of abrew tap
if the formula requires ittapUrl
: set if thetap
requires a specific URL
git
: install with agit clone
url
: the URL of the git repo to clonetarget
: the directory to clone the repo into
script
: install by fetching and running abash
scriptartifact
: install by fetching an artifact to a certain pathurl
: the URL of the artifact to fetchtarget
: the directory to fetch the artifact intoappendFilename
: whether to append the lasturl
segment to thetarget
command
: install by running a givenbash
command
On module load, all tools will be checked for presence on the system, even if they are not explicitly set in toolDeps
, unless the tool is marked as optional
.
The following checks can be configured:
checkCommand
: check for the presence of an executable in thePATH
(default)- the default check method. if not explicitly set, will use the tool name
- can be set to
true
to explicitly override one of the other check methods, such as when using thebrew
install method
checkBrew
: check withbrew
if its been installed- automatically used when the tool is using the
brew
install method with thecask
option set totrue
- automatically used when the tool is using the
checkPath
: check for the presence of the given filecheckEval
: run the given command and check the exit code
In addition to presence checking, a tool can optionally be configured to require a specific version (or range):
version
: the expected semantic version- will validate up to the
minor
version, not checkingpatch
- will validate up to the
versionCommand
: the command with which to get the tool's installed version
The following fields are unique to fiber
configurations:
fiberDeps
: whichfibers
must be loaded prior to this onemoduleConfig
: allows you to set overrides for child chains' configuration
Modify this config by running chiConfigModuleModify <fiber name>
.
chain
configurations are optional, and are merged with any matching parent moduleConfig
fields, higher-level ones overriding lower.
Modify this config by running chiConfigModuleModify <fiber name:chain name>
.
This chain provides a configurable secrets-management interface for other chains to use; it was designed with the pass
command in mind, but can be used with others, given a compatible CLI.
Configuration:
Add a section to your chiConfig with the command
to use:
{
"chains": {
"secret": {
"command": "pass"
}
}
}
Functions:
chiSecretGet
: retrieves a secret with the given name from the secret store
This project is used by: