[arnorhs]

I wouldn't put an .envrc file in source control. This seems like an anti-pattern.

I think it should be standard practice that you can pull and run a project without configuring environment variables. I agree with that. The defaults should work.

This is not always possible (when you have something that absolutely relies on a third party thing, which you need an environment variable for) - in which case you should be greeted with a helpful error telling you what environment variables you need to set up and why.

[NoThisIsMe]

It is absolutely not an anti pattern to check Direnv's `.envrc` in to source control, and if you don't then you're passing up on much of Direnv's value proposition.

Obviously don't put secrets in there. For secrets and overrides you can use separate a `.env` file which is not checked in, and source it in `.envrc` with `dotenv_if_exists`

[Fire-Dragon-DoL]

The moment you commit an envrc file, you disallow the developer from using direnv for that directory to configure stuff related to their machine. It is an anti pattern, it was never meant to be committed. Put an envrc.example in repo if you want, or an envrc.project in there and tell the dev to load it (load_if_exists in direnv)

[pxc]

You can use direnv in conjunction with sops or your favorite cloud-centric secrets management utility to automate secrets handling without writing any plaintext secrets (or any secrets at all, if you want) to version control.

.envrc is a whole bash script, so it can invoke command line tools that fetch secrets over the network or decrypt them from the disk.

[NoThisIsMe]

Yep that too