16 releases (5 breaking)
|0.6.6||Feb 22, 2021|
|0.6.5||Feb 15, 2021|
|0.5.1||Feb 1, 2021|
|0.5.0||Jan 27, 2021|
|0.0.1||Dec 23, 2020|
#313 in Command line utilities
136 downloads per month
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.
# Suppose you've got some directory structure ❯ mkdir -p projects/foo ❯ cd projects # In "projects", you want some shorthand for quickly pushing your branches ❯ sauce new Created /Users/danc/.local/share/sauce/projects.toml ❯ sauce set alias push='git push origin "$(git rev-parse --abbrev-ref HEAD)"' Setting push = git push origin "$(git rev-parse --abbrev-ref HEAD)" # Your project is, naturally, using 12-factor methodology, so you've got some # project specific environment variables you need to load! ❯ cd foo ❯ sauce set env foo=bar AWS_PROFILE=meow Setting foo = bar Setting AWS_PROFILE = meow # The core purpose! ❯ sauce Sourced ~/.local/share/sauce/projects/foo.toml ❯ env ... AWS_PROFILE=meow foo=bar # Note the cascaded loading of upstream values! ❯ push
cargo install sauce
- Download Linux/Mac binary from Releases
Currently explicitly supported shells include:
fish. The scaffolding exists to support other shells, which should
make supporting other common shells that might require
Loading things into the environment requires a minimal amount of shell code to be executed, so after installing the binary (suggestion below), you will need to add add a hook to your bashrc/zshrc/config.fish, etc.
eval "$(sauce --shell bash shell init)"
eval "$(sauce --shell zsh shell init)"
sauce --shell fish shell init | source
Depending on the level of similarity to the above shells, you may be
able to get away with using one of the above
shell init hooks until
explicit support is added
A thing which
sauce can load/unload is called a “target”.
Currently supported targets include:
sauce set env FOO=bar
sauce set alias g=git
sauce set function add 'echo $(expr $1 + $2)'
This is primary usecase is the
sauce command, no subcommand, no
arguments. This loads the current shell with all sauce targets (env
vars, aliases, and function) which apply to the current directory.
There are also a bunch of options to allow you to
customize the behavior of
sauce, for example
sauce --glob DATABASE*,
sauce --filter env:AWS_PROFILE, or
sauce --path ~.
The original motivation for central storage was due to getting a new
computer and needing to comb through ~50 repos to find all the random
.env files and gitignored notes and whatnot littered all over the
place to make sure nothing got left behind.
However just generally, colocating the sauce data with the actual folder introduces a number of technical, security, and usability issues that are circumvented through central storage.
A key feature of
sauce is that values are loaded in a cascading
fashion relative to the home directory.
This makes it easier to compose targets (env vars, aliases, and shell functions) among various locations, likely by utilizing the natural directory structure you might already have.
Given a directory structure
~/ work/ project/ repo/ repo2/ src/ otherproject/
Support you run
sauce at any folder level/depth, say
~/work/project/repo/. The values saved for the folders:
~/work/project/repo 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, if every folder had a saucefile,
you might see:
~/.local/share/ sauce.toml sauce/ project.toml project/ repo.toml repo2.toml repo2/ src.toml otherproject.toml
See the Configuration Reference on
For local development, it can be useful to enable the
This alters the behavior so that the shell hook(s) point to the absolute
location of the debug build.
An example alias that might be helpful could be:
[alias] build = 'cargo build --features dev && eval "$(./target/debug/sauce shell init)"'
At which point, you’re a quick
build away from being able to
around to test
sauce, while always pointing at your project version of
sauce for the current shell.