The approach of using direnv and putting .env files in directories encouraged me to pull more variables from other places in config files, or shell scripts, or global variables in a programming project, and put them in environment variables instead. It's very aligned with the 12 factor philosophy [1].

Also, many scripts start by just defining a bunch of variables -- and many of those, in terms of other variables. Say, a PROJECT_ROOT directory, and a PROJECT_DOCS directory defined relative to that, etc. Then, a bunch of command parsing logic, after defining all those default values, so the user can set values of their own. Then, finally, the script can start doing the thing it was put there for in the first place.

With the .envrc approach, some of that stuff is pulled out of the script (making it shorter and simpler) and considered part of the directory environment.

  [1] https://12factor.net/config

My biggest use is for configuring database connections. Create something like `FOODATABASE=postgres://user:password@server:port/name` and then whenever I am inside the project, I source the FOODATABASE environment variable wherever it is needed. Another convenience pattern I use with Django is to have a PROJECT_IS_DEBUG key -iff variable is defined, enable extra tracing functionality without requiring any development specific configuration files.

Example server pattern to default to production:

  if "PROJECT_IS_DEBUG" in os.environ:
    DEBUG = True
    ALLOWED_HOSTS = ["*"]
  else:
    # production configuration by default

All for a one-time configuration setup. A further boon of this workflow is that systemd natively supports an EnvironmentFile configuration, so you can re-use the same configuration format from development to production.

Projects I work on wind up with a bin/ directory containing any number of little helper scripts and tools. With direnv that dir can automatically be first in your PATH when you're in the project, but not on it at all when you're elsewhere. Ditto for, say, putting a Python project's virtualenv/bin folder on PATH or a NodeJS project's node_modules/.bin.

Projects I'm on also tend to wind up with an etc/ directory that configures things like PATH and tab completions for a good baseline experience - think of it as standardizing and isolating the snippets many projects tell you to put in your ~/.bashrc to work on the project.

Direnv makes it easy to automatically load those, too.

It really did revolutionize the way I work, by making it trivial to make projects much more self-contained, the way I'd always wanted them to be but hadn't been quite sure how to achieve.

I've only used Nix for managing my personal installed package on OS X so far, but I believe direnv works really well in tandem with Nix - use a Nix file to define your project's dependencies and use direnv to automatically activate all those dependencies whenever you're in the project's directory.

I place a .envrc at the root of our monorepo with a handful of env vars that configure stuff like PATH (to point to the various scripts, tools, and executables that are used in the dev environment), override the sane default config files with an environment variable (extremely useful when chasing down specific bugs) and to redirect or control logging and debug info when running tools and systems.

It makes it a breeze to pull in a commit and set up a development harness that pokes at whatever thing I need to poke at in my local environment. And it does it without changing a line of code or command line invocation, which is a big deal in polyglot environments with various build constraints (not passing -DFLAG=thing is enormous in a big C/C++ code base, for example).

Even just being able to point whether a service is looking at a dev/production/local service/database is a big deal if you've invested in IaC and don't want to mess with any config files to do your work (as .envrc is probably in your .gitignore).

A very nice use of direnv is automatically calling virtualenv's `activate` on directory entry, so you don't need to do that yourself.

When I was working with google cloud it would have been nice to have gcloud change project depending on the folder I was in.

Kind of imagine if git didn't change repo when you switched directory, that was how it felt.