Jonas Chevalier

It's the same issue. The aliases are defined in the `.envrc` evaluation context but then cannot be exported to the host shell.

It's a valid observation but I don't really know if there is a way to fix it. direnv basically depends on callbacks that are provided by the shell to update...

Thanks for the report! If somebody wants to tackle this, the `DetectShell` function should be changed to return (Shell, error). That way the consumer is forced to handle that case.

You can run `eval "$(direnv export bash)"` manually, whenever you enter a folder that has a .envrc. The bash variable declaration seems to be compatible with ksh. I played a...

Sounds good! I would be happy to accept a PR for fish completion. I think it's just a matter of copying the completions folder and updating the GNUMakefile install target.

Sounds good. I'm happy to keep the set of features small. So let's wait until somebody else is requesting for it :) (and motivated enough to finish the job)

The current workaround is to add `dotenv` in the `.envrc`. It's part of the stdlib and loads the `.env` file. I am not against extending direnv to support that scenario.

Yeah, have a look. We have a config.toml file now where the option could be introduced. I haven't really thought out the best approach to handle this yet. Maybe template...

I think that we need a template system that can load pre-defined `.envrc` files when specific files are found. The lookup would then change from `for each folder up until...

one approach is to add this to the `.envrc`: ```sh [[ -f .envrc.private ]] && source_env .envrc.private ``` that gives a level of extensibility for local overrides