All, I''ve run into a few cases recently where I have environments that are nearly (or totally) identical, except for the database. For example, I have a "live" environment locally where I pull production data for load testing or triage, and I generally want it to behave like "development". Similar situations occur for continuous-integration or staging boxen that should look an awful lot like development (or production), but not quite. In order to make these sorts of situations pleasantly self-documenting, I''ve patched the Initializer with a little helper: # config/environments/live.rb acts_like :development Is this a patchworthy feature? I''d be happy to submit my change and tests if other people see any value here. As this changes Rails'' initalization process, it''s a bit difficult to elegantly expose as a plugin. ~ j. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
> I''ve run into a few cases recently where I have environments that are > nearly (or totally) identical, except for the database. For example, I > have a "live" environment locally where I pull production data for > load testing or triage, and I generally want it to behave like > "development". Similar situations occur for continuous-integration or > staging boxen that should look an awful lot like development (or > production), but not quite. > > In order to make these sorts of situations pleasantly > self-documenting, I''ve patched the Initializer with a little helper: > > # config/environments/live.rb > acts_like :development > > Is this a patchworthy feature? I''d be happy to submit my change and > tests if other people see any value here. As this changes Rails'' > initalization process, it''s a bit difficult to elegantly expose as a > plugin.Can''t you just require common pieces of code from each of the environments? If not, perhaps we should make that simpler to do. The initializers feature also takes care of a lot of the duplication I used to have between ''production'' and ''staging'' at present, what stuff are you left with in both files? -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ 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 6/15/07, Michael Koziarski <michael@koziarski.com> wrote:> > # config/environments/live.rb > > acts_like :development> Can''t you just require common pieces of code from each of the > environments? If not, perhaps we should make that simpler to do.In the case of two environments that share common pieces of code, absolutely. Where I''ve found this most useful, though, is in a case where an environment is either *precisely* the same as another (except for the database, e.g., running with a copy of live data on your local dev machine), or differs in the most minor of ways. This is really just a bit of sugar, of course. It''s the equivalent of: # in config/environments/live.rb # live should act exactly like development, except for the database eval(IO.read("#{RAILS_ROOT}/config/environments/development.rb")) As sugar, it may not be a good addition. I sure think "acts_like :development" is nice, though.> The initializers feature also takes care of a lot of the duplication I > used to have between ''production'' and ''staging'' at present, what > stuff are you left with in both files?Love the initializers. Leftover differences between, say, production and staging are mostly totally reasonable stuff, like email addresses or server names/IP''s. ~ j. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
> In the case of two environments that share common pieces of code, > absolutely. Where I''ve found this most useful, though, is in a case > where an environment is either *precisely* the same as another (except > for the database, e.g., running with a copy of live data on your local > dev machine), or differs in the most minor of ways.Couldn''t you achieve this with symlinks though? -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ 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 6/15/07, Michael Koziarski <michael@koziarski.com> wrote:> > In the case of two environments that share common pieces of code, > > absolutely. Where I''ve found this most useful, though, is in a case > > where an environment is either *precisely* the same as another (except > > for the database, e.g., running with a copy of live data on your local > > dev machine), or differs in the most minor of ways. > > Couldn''t you achieve this with symlinks though?Absolutely. The only reason I can think of to use something like my acts_like sugar instead of symlinks is clarity and maintainability over time: I think it''s good that anybody who cats/edits the file will immediately know that it mirrors another environment, which isn''t necessarily the case with a symlink. We''re all moving at lightspeed ''round here, and the more explicit information the better. Symlinks aren''t sneaky, but they''re certainly not always obvious. That said, the combination of initializers and symlinks makes my justification pretty thin. :) ~ j. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---