Sauce
The central truth is the central truth, and nothing that I care about is relative
A tool to help manage context/project specific shell-things like environment variables.
Core Goals:
- Store all data centrally, not relative to the directory being sauced
- Cascade data from parent directories downwards
Example Workflow
# Suppose you've got some new directory structure
# You want to start recording things here
# My "foo" project has got some corresponding aws profile
# The "bar" subdirectory has something more specific
# The core purpose!
AWS_PROFILE=foo
foo=bar
Targets
A thing which sauce
can load/unload is called a “target”.
Currently supported targets include:
- environment variables
- aliases
Planned/Ideally supported targets include:
- functions
- arbitrary kv
Features
sauce
command
The primary usecase is the sauce
command. Explicitly no arguments, you
load the environment with all sauce targets, cascaded from the uppermost
parent.
Cascades
Given a directory structure
~/ projects/ foo/ subfoo/ bar/
You can run sauce
at any folder level/depth, say subfoo
. The values
saved for the folders: ~
, ~/projects
, ~/projects/foo
, and
~/projects/foo/subfoo
will all be loaded.
The more specific/deep folder’s values will take precedence over the values of more general/shallow folders.
All saucefiles are located in the $XDG_DATA_HOME/sauce
folder, after
which the folder structure mirrors that of the folders who’s values are
being tracked. Given the above example you might see:
~/.local/share/sauce/
foo/
subfoo.toml
foo.toml
bar.toml
projects.toml
sauce add <target-type> NAME=value
For example, sauce add var AWS_PROFILE=foo FOO=bar
.
This is convenient when you realize you want to sauce
a var or
whatever. There is also sauce edit
which will open your $EDITOR
so
you can bulk update whatever values you like.
sauce --as foo
Any key-value pair can be tagged with, you might call “namespaces”.
Consider an env var definition
= { = "projectname-dev", = "projectname-uat", = "projectname-prod"}
Given a sauce
, you will get the “default” namespace
(i.e. AWS_PROFILE=projectname-dev) for this value, as well as all other
unnamespaced values.
Given sauce --as prod
, you will get the “prod” namespace
(i.e. AWS_PROFILE=projectname-prod) for this value, as well as all
other unnamespaced values.
Planned Features
- more targets (in order): functions, arbitrary key-value pairs
- “strategies” (nested shell vs in-place alterations of the current
shell)
- Given strategies, the ability to unset/revert alterations in a more
robust way is enabled (i.e. kill the subshell). Compared to the
in-place modification strategy which essentially requires that
sauce
maintains sole control over all tracked variables (because it can/willunset
them if asked).
- Given strategies, the ability to unset/revert alterations in a more
robust way is enabled (i.e. kill the subshell). Compared to the
in-place modification strategy which essentially requires that
- pipe
sauce show
to a pager when beyond a full terminal height - colorized output
- Ability to use shell hooks to automatically perform i.e.
sauce
oncd
(i.e. direnv)