Add ability to load env-t settings from each *.env file.

[DavydenkovM]

I think it would be a good idea to autoload settings from any *.env file in Rails app in addition to '.env' or ".env.#{Rails.env}".

With this little patch we can create files:

• "config/environments/constants.env" (All non-secret constants)
• "tokens.env" (file with secrets).

This would be helpful for capistrano deployment:

set :linked_files, %w{config/database.yml config/environments/tokens.env}

We can link only tokens.env, without constants.env.

In addition I think 'semantic_name.env' would be more semantic than just '.env'.

Thanks in advance for your attention!

UPDATE: All previous '.env' and '.env.*' conventions will work as before.

[markrebec]

I'm personally against this change. It would cause a lot of compatibility issues for anyone who relies on the current behavior - they might have a .env.development and .env.test with different values for certain keys, and this new behavior would break that.

As for the file naming conventions, .env and .env.* have been the convention since the project was created (as far as I know), and I don't know there's much reason to change it at this point.

For your particular case, maybe you could just automatically include any *.env files manually as you're doing here either in your config/application.rb or a config initializer. Otherwise, I'd suggest maybe making this a separate gem with a railtie that does the autoloading (you could call it dotenv-autoloader or something)... that way the behavior would be optional.

[DavydenkovM]

All the previous .env and .env.* will work as before. You can just add files *.env wherever you want as an option

[bkeepers]

I really like this idea. Would it make sense to limit it to config? Or at least exclude test|spec?

Would you mind submitting it as a pull request to https://github.com/bkeepers/dotenv-deployment? Once #95 is merged, all the multiple environment stuff will go there.