Or to phrase it another way:
While developing in a distributed (multi-developer) environment,
how do you keep settings local to your own system out of the svn
repository?
e.g, in config/environment.rb, you want to have an entry like
config.action_mailer.smtp_settings = { :address => “smtp.example.com”,
…
In a Java environment you’d have a build.properties file that would
substitute in your appropriate values; what’s the Rails way here?
TIA,
Hassan S. ------------------------ [email protected]
On 21 Jan 2008, at 15:10, Hassan S. wrote:
There’s development.rb, production.rb etc… which allow you to have
per environment settings for stuff like that.
Fred
On Jan 21, 2008 7:19 AM, Frederick C. [email protected]
wrote:
There’s development.rb, production.rb etc… which allow you to have
per environment settings for stuff like that.
So you’re saying to just exclude development.rb from being included
in SVN, then?
But it’s not just stuff in that one file. For example, there’s a
reference
to “@host” in user_mailer.rb (restful_authentication) that needs to be
configured for each developer.
@body[:url] = "http://#{@host}/activate/#{user.activation_code}"
Are you saying then that @host and any other desktop-local variables
anywhere should be set in environments/development.rb?
–
Hassan S. ------------------------ [email protected]
On 21 Jan 2008, at 16:06, Hassan S. wrote:
On Jan 21, 2008 7:19 AM, Frederick C.
[email protected] wrote:
There’s development.rb, production.rb etc… which allow you to have
per environment settings for stuff like that.
So you’re saying to just exclude development.rb from being included
in SVN, then?
I wouldn’t go that far - I got the impression from the example you
gave that you were more interested in production vs development
settings.
anywhere should be set in environments/development.rb?
Something like the current host does sound like something that is part
of the environment, and hence fodder for development.rb. Obviously
this isn’t so great if your going to have different ones for each
developer (which isn’t something I’ve needed)
Fred
On Jan 21, 2008 8:24 AM, Frederick C. [email protected]
wrote:
So you’re saying to just exclude development.rb from being included
in SVN, then?
I wouldn’t go that far - I got the impression from the example you
gave that you were more interested in production vs development
settings.
Well, not really – there’s settings for the production server, yes,
but there’s also development-mode settings for the integration
server which will be different from those on each developer’s
desktop.
Something like the current host does sound like something that is part
of the environment, and hence fodder for development.rb. Obviously
this isn’t so great if your going to have different ones for each
developer (which isn’t something I’ve needed)
I can’t imagine any distributed team would not face this issue.
Any other suggestions?
–
Hassan S. ------------------------ [email protected]
Hassan S. wrote:
I can’t imagine any distributed team would not face this issue.
Any other suggestions?
–
Hassan S. ------------------------ [email protected]
Hassan,
Modify config/environment.rb to load user specific configuration files…
since environment.rb is ruby, you can also add smarts to conditionally
load files on environment conditions, user defined properties, etc…
Everyone will still have the same version of config/environment.rb but
can have drastically different environments based on their own user
settings.
hth
ilan
On Jan 21, 2008 9:01 AM, Ilan B. [email protected]
wrote:
Modify config/environment.rb to load user specific configuration files…
since environment.rb is ruby, you can also add smarts to conditionally
load files on environment conditions, user defined properties, etc…
Everyone will still have the same version of config/environment.rb but
can have drastically different environments based on their own user
settings.
Aha, that sounds exactly like what I need 
Thanks much!
Hassan S. ------------------------ [email protected]
Our teams leverage an approach wherein we load data from config.yml.
In config,yml, we store all of our settings and ignore that in SVN.
This
config file is structured just like the database.yml file, but it
contains
every setting that could change, from authorize.net keys for cc
processing
to what type of email system to use (sendmail, smtp, etc). We then just
load those into a hash stored in a constant in environment.rb
We can then use capistrano to build that file on the servers when we
deploy
it
On Jan 21, 2008 12:13 PM, Hassan S. [email protected]
On Jan 21, 2008 7:24 PM, Brian H. [email protected] wrote:
In config,yml, we store all of our settings and ignore that in SVN. This
config file is structured just like the database.yml file, but it contains
every setting that could change, from authorize.net keys for cc processing
to what type of email system to use (sendmail, smtp, etc). We then just
load those into a hash stored in a constant in environment.rb
Thanks, I’ll have a play with that as well, since I’m just getting
started
with a multi-dev RoR project and looking at best practices.
Nothing like jumping into the deep end
Hassan S. ------------------------ [email protected]