Add automatic ".env" compatibility

[aude]

This is work towards using .env if there is no .envrc (#284).

I love what direnv does, and would really like to use it more 😄 Having automatic "fallback" to .env would remove a lot of friction for me. I figured the best way to achieve that would be to help implement it.

The code is WIP now. It works, but might be a bit wrong/incoherent. I would appreciate any feedback, I'm quite new to Go.

1. Naming and coding style could be off with regard to the rest of the project, just change it however you'd like.
2. .env files are not loaded "layered" now, same as .envrc. I would personally like .env loading to work by default like source_up. Thoughts?
3. I changed DIRENV_DIR to DIRENV_FILE, to keep track of the RC file used. Is that breaking anything?
4. RC file "detection" is done by simply checking the file name. I think this is a bit cheap, maybe there should be a type attribute on the RC object instead. Thoughts?
5. I haven't added any tests for .env loading. I'd like to add some, but could take some advice what should be tested.

[zimbatm]

This introduces a few issues with backward-compatibility:

• people rely on the existence of $DIRENV_DIR to check if an environment has been loaded for example
• the .env might get loaded even if this is not the user's intention
  I don't have a great solution to fix that unfortunately. Ideally the behaviour would be configurable in some way.

[aude]

Thanks for checking!

• I can change the code to have both DIRENV_FILE and DIRENV_DIR, that sounds better now knowing that DIRENV_DIR is used.
• The .env will only be loaded if the user has accepted it via direnv allow, just like for .envrc. If you haven't allowed the .env file, you'll get this error message:
  direnv: error .env is blocked. Run `direnv allow` to approve its content.

Does this answer your questions?

[aude]

I have been using this fork for the last week now without issues, for what it's worth.

[aude]

Added back DIRENV_DIR, so that's not an issue anymore.

[alvis]

Thank you @aude. This PR is highly anticipated!
@zimbatm: shell we merge this?

[aude]

I did not mean to close this PR. I just rebased it on master, to keep the PR up to date.

I think one approach here could be to merge it and get it out to people. Then we could add improvements as we go, if needed.

I've been using this code successfully since January 3, 2019, so that could vouch for it working.

[schickling]

[zimbatm]

@aude I added some minimal testing, which probably needs to be fixed. Having it work on your machine is not nearly sufficient to make sure it doesn't break other people's workflows as direnv is used in many different contexts. Please also amend the documentation to advertise the fact that direnv is now also looking for .env files.

[aude]

Thanks for taking a look. I'll take a look at the tests and add documentation.

[aude]

Sorry for letting you guys down here. I lost motivation some months ago, I'm currently not motivated to finish the PR.

Hoping that changes, can't promise anything though.

[joaomcarlos]

!

[varac]

Ping, any progress here ?

[zimbatm]

@varac do you want to pick this up?

[JakeElder]

Is this likely to be merged? I'd like to see this functionality included. Great work with direnv, thank you.

[zimbatm]

It depends on somebody stepping up and fixing the PR.

[JakeElder]

It depends on somebody stepping up and fixing the PR.

Understood. I'd like to have a go but have very little time, knowledge of bash and experience with go, so I'm not best equipped 🤓. Thanks again for the package.

[robert-r-meyer]

@aude @zimbatm I'd be happy to finish this off given commit permissions to the fork.

[felipecrs]

I created a PR as continuation of this: #845

It should be ready to review, any feedback is welcome.

[zimbatm]

Released in v2.30.1!