The default value for RAILS_ENV is set to "development" in
initializer.rb,
which is loaded right after boot.rb has determined the boot strategy.
I created a "config/preinitializer.rb" which was supposed to provide
another
default value for RAILS_ENV ("staging" or "production",
depending on the
host), but it doesn''t work in all cases. Specifically, commands
executed by
"console", "dbconsole", "runner" and
"server" scripts all set RAILS_ENV to
"development" as default and ruins my preinitializer idea since these
scripts happen before the actual initialization phase.
The workaround right now is to hardcode the RAILS_ENV value in
preinitializer.rb without respecting the ENV["RAILS_ENV"] variable,
but that
disables the possiblity that I actually start the app in some custom
environment other than what I wanted to hardcode for this host.
What I would like to do is remove the "development" default from
script/console, script/runner and script/server (removing it from
"dbconsole" is not possible since it doesn''t load the
environment) and
unless anyone can find an objection to this, I will be posting a patch.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---
+1 I''ve had similar problems. -John On Tue, Oct 13, 2009 at 12:53 PM, Mislav Marohnić <mislav.marohnic@gmail.com> wrote:> The default value for RAILS_ENV is set to "development" in initializer.rb, > which is loaded right after boot.rb has determined the boot strategy. > I created a "config/preinitializer.rb" which was supposed to provide > another default value for RAILS_ENV ("staging" or "production", depending on > the host), but it doesn''t work in all cases. Specifically, commands executed > by "console", "dbconsole", "runner" and "server" scripts all set RAILS_ENV > to "development" as default and ruins my preinitializer idea since these > scripts happen before the actual initialization phase. > > The workaround right now is to hardcode the RAILS_ENV value in > preinitializer.rb without respecting the ENV["RAILS_ENV"] variable, but that > disables the possiblity that I actually start the app in some custom > environment other than what I wanted to hardcode for this host. > > What I would like to do is remove the "development" default from > script/console, script/runner and script/server (removing it from > "dbconsole" is not possible since it doesn''t load the environment) and > unless anyone can find an objection to this, I will be posting a patch. > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Tue, Oct 13, 2009 at 9:53 AM, Mislav Marohnić <mislav.marohnic@gmail.com> wrote:> The default value for RAILS_ENV is set to "development" in initializer.rb, > which is loaded right after boot.rb has determined the boot strategy. > I created a "config/preinitializer.rb" which was supposed to provide another > default value for RAILS_ENV ("staging" or "production", depending on the > host), but it doesn''t work in all cases. Specifically, commands executed by > "console", "dbconsole", "runner" and "server" scripts all set RAILS_ENV to > "development" as default and ruins my preinitializer idea since these > scripts happen before the actual initialization phase. > The workaround right now is to hardcode the RAILS_ENV value in > preinitializer.rb without respecting the ENV["RAILS_ENV"] variable, but that > disables the possiblity that I actually start the app in some custom > environment other than what I wanted to hardcode for this host. > What I would like to do is remove the "development" default from > script/console, script/runner and script/server (removing it from > "dbconsole" is not possible since it doesn''t load the environment) and > unless anyone can find an objection to this, I will be posting a patch.+1 Also, the default generated test_helper hardcodes RAILS_ENV to test (or used to, I didn''t check master). I guess that''s the best place, but thought I''d mention it in case it is relevant to your patch. -- Chad
B.A. ''Bad Attitude'' Baracus
2009-Oct-14 03:11 UTC
Re: RAILS_ENV hardcoded in too many places
It does seem like a bad idea to have it hardcoded to development in initializer.rb. I''ve never run into your problem, though. quick fix: set RAILS_ENV to the appropriate value in your system wide bashrc on staging and production machines. even easier with stuff like puppet and chef. -B.A. On Oct 13, 2009, at 12:09 PM, John Trupiano wrote:> +1 I''ve had similar problems. > > -John > > On Tue, Oct 13, 2009 at 12:53 PM, Mislav Marohnić <mislav.marohnic@gmail.co > m> wrote: > The default value for RAILS_ENV is set to "development" in > initializer.rb, which is loaded right after boot.rb has determined > the boot strategy. > > I created a "config/preinitializer.rb" which was supposed to provide > another default value for RAILS_ENV ("staging" or "production", > depending on the host), but it doesn''t work in all cases. > Specifically, commands executed by "console", "dbconsole", "runner" > and "server" scripts all set RAILS_ENV to "development" as default > and ruins my preinitializer idea since these scripts happen before > the actual initialization phase. > > The workaround right now is to hardcode the RAILS_ENV value in > preinitializer.rb without respecting the ENV["RAILS_ENV"] variable, > but that disables the possiblity that I actually start the app in > some custom environment other than what I wanted to hardcode for > this host. > > What I would like to do is remove the "development" default from > script/console, script/runner and script/server (removing it from > "dbconsole" is not possible since it doesn''t load the environment) > and unless anyone can find an objection to this, I will be posting a > patch. > > > > > >
>> What I would like to do is remove the "development" default from >> script/console, script/runner and script/server (removing it from >> "dbconsole" is not possible since it doesn''t load the environment) and >> unless anyone can find an objection to this, I will be posting a patch.This sounds like a good change to me.> +1 > > Also, the default generated test_helper hardcodes RAILS_ENV to test > (or used to, I didn''t check master). I guess that''s the best place, > but thought I''d mention it in case it is relevant to your patch.I dunno about changing this one, accidentally running your tests against another environment can be pretty catastrophic. -- Cheers Koz
On Wed, Oct 14, 2009 at 22:39, Michael Koziarski <michael@koziarski.com>wrote:> > Also, the default generated test_helper hardcodes RAILS_ENV to test > > (or used to, I didn''t check master). I guess that''s the best place, > > but thought I''d mention it in case it is relevant to your patch. > > I dunno about changing this one, accidentally running your tests > against another environment can be pretty catastrophic.I don''t think Chad suggested it needs to be changed; he just pointed out the only other place where RAILS_ENV needs to be hardcoded (apart from initializer.rb) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Wed, Oct 14, 2009 at 05:11, B.A. ''Bad Attitude'' Baracus <b.a@baracus.org>wrote:> > It does seem like a bad idea to have it hardcoded to development in > initializer.rb. >Well, somewhere it *does* have to default to "development".> > I''ve never run into your problem, though. quick fix: set RAILS_ENV to > the appropriate value in your system wide bashrc on staging and > production machines.Yeah I got that a lot. Problem is, there are other apps on the same machine running in different environments. I don''t want a system-wide setting, I want it per-app so that''s why I''m using a preinitializer. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Wouldn''t it make more sense to set it in the vhost (if you''re using Passenger) or with your Mongrel config (or the like). I write app''s that live on many environments (qa, stage, prod, admin, ci, dev, test, etc.) and have never once had an issue with RAILS_ENV. On Oct 15, 9:58 am, Mislav Marohnić <mislav.maroh...@gmail.com> wrote:> On Wed, Oct 14, 2009 at 05:11, B.A. ''Bad Attitude'' Baracus > <b...@baracus.org>wrote: > > > > > It does seem like a bad idea to have it hardcoded to development in > > initializer.rb. > > Well, somewhere it *does* have to default to "development". > > > > > I''ve never run into your problem, though. quick fix: set RAILS_ENV to > > the appropriate value in your system wide bashrc on staging and > > production machines. > > Yeah I got that a lot. Problem is, there are other apps on the same machine > running in different environments. I don''t want a system-wide setting, I > want it per-app so that''s why I''m using a preinitializer.
On Fri, Oct 16, 2009 at 05:28, Andrew Bloom <akbloom@gmail.com> wrote:> > Wouldn''t it make more sense to set it in the vhost (if you''re using > Passenger) or with your Mongrel config (or the like). I write app''s > that live on many environments (qa, stage, prod, admin, ci, dev, test, > etc.) and have never once had an issue with RAILS_ENV.I''m not having issues with RAILS_ENV. I''d just like if you *didn''t* specify it, that it defaults to some pre-configured environment other than "development". The problem with setting environment everywhere explicitly means you have to check your Passenger/Mongrel config, god recipes, delayed_job workers, scripts than run rake tasks, cron jobs, scripts that run migrations ... and let''s not forget you have to specify the environment every time you open script/console. It''s getting a little tedious, especially because I want to re-use configurations I already have for a different app and not care whether that app runs in a different environment than this one. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---