Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not automatically unload direnv for subfolders (that are not allowed) #877

Closed
christiantakle opened this issue Jan 4, 2022 · 5 comments
Labels

Comments

@christiantakle
Copy link

christiantakle commented Jan 4, 2022

The autoload .env (#845) broke our monorepo that uses nix.

Many sub projects that have .env.

<repo>/.envrc
<repo>/default.nix
<repo>/packages/a/.env
<repo>/packages/a/scripts/.. (broken missing deps from default.nix)
<repo>/packages/b/.env
<repo>/packages/b/scripts/.. (broken missing deps from default.nix)
...

a and b no longer have access to tools provided by <repo>/.envrc how is one suppose to handle this now?

Expected behavior
To keep the context of the already initialized direnv. That is do not unload the env on subfolder that just happen to contain a .env file if it is not explicitly allowed.

Environment

  • OS: macOS Monterey
  • Shell: zsh
  • Direnv version 2.30.2

Let me know of more info is needed.

Cheers

@pepakriz
Copy link

pepakriz commented Jan 4, 2022

I'm using a very similar technique in our monorepo:

<projectDir>/.envrc // here are secrets, bin path configuration etc for my development account (not versioned)
<projectDir>/<repo>/a/.env // here is ENV config for docker-compose, but I don't want to load it automatically
<projectDir>/<repo>/b/.env // here is ENV config for docker-compose, but I don't want to load it automatically

and since 2.30.x I'm not able to keep envs loaded inside the <projectDir>/<repo>/x/ directories.

@christiantakle
Copy link
Author

Solution: #878
Hope that autoload .env becomes opt-in instead of an opt-out.

@Groxx
Copy link

Groxx commented Feb 15, 2022

Yep, same here. The auto-unload is causing issues, and it can't even be worked around by denying the problematic .env(rc) file.

Seems like this was pre-existing behavior, but .env files now being supported is just making it happen (a lot) more often. Personally I'd always rather keep my parent-.envrc setup until explicitly replaced by something I've allowed, not dropping it any time something happens to change.

@christiantakle
Copy link
Author

@herkhinah
Copy link

This only fixes the issue if using an .env in the subdirectory when having a blocked .envrc in the child directory the parent directory's .envrc still get's unloaded.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

4 participants