1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
|
---
title: Some Direnv Patterns
date: 2024-05-01T21:17:03-04:00
---
A by-no-means-exhaustive list of [direnv] configuration techniques I've found helpful.
[direnv]: https://direnv.net/
<!--more-->
## Local configuration only
Situation: the project requires environment variables to function. There is no need to capture how those variables should be provisioned in source control, or no consensus to do so among the contributors.
Approach:
* Put `.envrc` in the project root.
* Mark `.envrc` to be locally ignored (eg. via `.git/info/exclude`, for Git).
* Store environment settings there.
## Shared configuration, local variations
Situation: the project requires environment variables to function. For development, there is a consensus to use direnv, but individual values cannot or should not be captured in source control.
Approach:
* Put `.envrc` in the project root, and check it into source control.
* Use [`source_env_if_exists .envrc.local`][seie] in `.envrc`.
* Ensure that `.envrc.local` is marked as ignored in source control (eg. via `.gitignore`, for Git).
* Put personalization in `.envrc.local` (where it won't be checked in), and shared settings in `.envrc` (where they can be checked in).
[seie]: https://direnv.net/man/direnv-stdlib.1.html#codesourceenvifexists-ltfilenamegtcode
## Common environment settings across multiple projects
Situation: multiple projects require identical environment variable sets. These projects share a parent directory, which also contains projects that do not need those environment variables.
For me, this is my AWS creds, which are used by multiple projects inside of my `~/Projects` directory, but not by everything there.
Approach:
* Put the common configuration in the parent directory, in files named `.envrc.SUFFIX` for some appropriate suffix (`.envrc.aws`, for example).
* Use `source_up .envrc.aws` to load them (from `.envrc.local`, `.envrc`, or by any other means) in the projects that need them.
## Tokens in a password manager
Situation: you have confidential authentication tokens that you need to provide in order to access an external service. You don't want them on the filesystem.
Approach:
* Use your password manager's CLI tool from inside of `.envrc` or an included configuration. (This meshes well with the `.envrc.local` approach). For example:
```bash
export AWS_ACCESS_KEY_ID=$(op item get AWS-Development --field 'access key id')
export AWS_SECRET_ACCESS_KEY=$(op item get AWS-Development --field 'secret access key')
```
Caveat: Many password managers implicitly start an agent process, which lurks in the background facilitating access. [This agent can cause direnv to wait indefinitely](https://github.com/direnv/direnv/issues/662).
|
