# Comparison to existing tools

Why would you choose to use `sauce` over certain alternatives? `sauce`
**does** have significant conceptual feature overlap with, in
particular, `direnv`, but the additional features may make it worth
using `sauce` instead!

Features which distinguish `sauce` from **all** the below alternatives

- Cascading loading of values from upstream directories

  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.

  For work, I tend to end up with directory structures like:

    ~/
      work/
        project/
          project-repo1/
          project-repo2/
        project2/
          project-repo1/

  Given that kind of structure, it can be very easy and natural to
  manage env vars, but especially functions and aliases at the most
  obvious level of specificity without needing to repeat common things
  inside each project.

- Central storage of the values

  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.

  In practice, I’ve found that there are numerous problems with storing
  your (equivalent to `.env`/`.envrc` files locally to the repo. In fact
  `direnv` added a whole additional feature `direnv allow` to work
  around that fact.

## `dotenv`

`dotenv` is the more obvious of the two, which is specifically for the
loading of environment variables, which is essentially the primary
usecase of `sauce`.

In a world where you only ever run `sauce` (and only use environment
variables), `dotenv` and `sauce` are very similar. Essentially the only
difference in this case would be that `sauce` stores its data centrally,
rather than inside the project directory.

The main advantage, are `sauce --as <context>`. In order to reproduce
this behavior, you need multiple dotenv files, (with all common values
duplicated, or contained in yet another file).

I find choice of `toml` files for `sauce`, while not necessarily
important to the actual featureset of `sauce`, to be useful because it
supports multiline strings. With `dotenv`, I often find myself needing
to manually quote or escape certain values containing shell special
characters in a way that I haven’t with toml (particularly with
multiline values or json).

## `direnv`

`direnv` is likely the other tool people are most likely to think of
looking at the initial pitch.

Given that `direnv`, very executes raw shell code directly for the given
folder, it can essentially do anything. And that includes anything
`sauce` can do, assuming you write all the shell code to actually do the
thing.

The advantage, lies in the fact that `sauce` is specifically tailored to
the usecases documented throughout. That means, it’s just a lot easier
to get the behaviors of `sauce` compared to writing the shell code (for
each project). Reproducing things like `sauce --as prod` or
`sauce --glob database*` would be significantly more involved.

Finally, the whole `direnv allow/deny` workflow exists specifically to
avoid the security concern originated due to executing shell code found
in some random folder (at least to my understanding). This is one of the
fatal flaws of storing the data directly within the folder being
operated on, and one of the reasons `sauce` stores its data centrally.