{"action":"closed","issue":{"url":"https://api.github.com/repos/bkeepers/dotenv/issues/45","labels_url":"https://api.github.com/repos/bkeepers/dotenv/issues/45/labels{/name}","comments_url":"https://api.github.com/repos/bkeepers/dotenv/issues/45/comments","events_url":"https://api.github.com/repos/bkeepers/dotenv/issues/45/events","html_url":"https://github.com/bkeepers/dotenv/issues/45","id":16684894,"number":45,"title":"Rake tasks in Rails always initialized in \"development\"","user":{"login":"bkeepers","id":173,"avatar_url":"https://avatars.githubusercontent.com/u/173?v=3","gravatar_id":"","url":"https://api.github.com/users/bkeepers","html_url":"https://github.com/bkeepers","followers_url":"https://api.github.com/users/bkeepers/followers","following_url":"https://api.github.com/users/bkeepers/following{/other_user}","gists_url":"https://api.github.com/users/bkeepers/gists{/gist_id}","starred_url":"https://api.github.com/users/bkeepers/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bkeepers/subscriptions","organizations_url":"https://api.github.com/users/bkeepers/orgs","repos_url":"https://api.github.com/users/bkeepers/repos","events_url":"https://api.github.com/users/bkeepers/events{/privacy}","received_events_url":"https://api.github.com/users/bkeepers/received_events","type":"User","site_admin":true},"labels":[{"url":"https://api.github.com/repos/bkeepers/dotenv/labels/bug","name":"bug","color":"fc2929"}],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2013-07-12T14:44:29Z","updated_at":"2015-01-22T03:05:43Z","closed_at":"2015-01-22T03:05:43Z","body":"The first line of `Rakefile` in any rails app is:\r\n\r\n```ruby\r\nrequire File.expand_path('../config/application', __FILE__)\r\n```\r\n\r\nThis causes dotenv to always be initialized in \"development\" (loading `.env` and `.env.development`) unless `RAILS_ENV` is explicitly set in the environment before running `rake`, which leads to unexpected results when running rake tasks that affect other environments. For example, put a variable in `.env.test` and run `rake test` to see that the variable is not properly loaded.\r\n\r\nDotenv currently [initializes as soon as the Railtie is loaded](https://github.com/bkeepers/dotenv/blob/ac382273b8421a8c302fd387e8e1240a8e20af5b/lib/dotenv/railtie.rb#L14) so `ENV` variables can be used in `config/application.rb` (see #10). Dotenv also [avoids overriding existing variables](https://github.com/bkeepers/dotenv/blob/ac382273b8421a8c302fd387e8e1240a8e20af5b/lib/dotenv/environment.rb#L44) so it doesn't clobber values set in the shell environment. So once dotenv has been initialized, changing the `RAILS_ENV` and re-initializing doesn't change anything.\r\n\r\nIf the [Rails boot process](http://api.rubyonrails.org/classes/Rails/Application.html#label-Booting+process) created a clear distinction between bootstrap, configuration, and initialization in the startup process, then dotenv could hook in before the configuration step. But unfortunately `config/application.rb` requires code and provides application configuration.\r\n\r\nHere are a few options to fix this issue. I would love other suggestions.\r\n\r\n1. Remove implicit environment support. Instead of automatically loading `.env.test`, we could add a `:force` option and the README could encourage users to add `Dotenv.load '.env.test', :force => true` to their spec or test helper.\r\n\r\n2. Add `Dotenv.reload` which gets called before initialization. This would track which variables were initially set by dotenv, and reread the configs. This adds a lot of flexibility, but at the cost of some complexity and could lead to unexpected behavior where `config/application.rb` and initializes are loaded with different configurations.\r\n\r\n3. Discourage use of `ENV` variables in `config/application.rb` and wait until initialization to load dotenv. This was the original behavior, but is annoyingly inconsistent with dotenv's goal of being an unobtrusive bridge for environment variables.\r\n\r\n~~Personally, I'm leaning toward option 1. It replaces complexity with explicit action.~~ Edit: See comment below."}}