RoR equivalent of Ant's build.properties?

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,

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", ...

There's development.rb, production.rb etc... which allow you to have
per environment settings for stuff like that.

Fred

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?

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.

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?

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

> 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 Schroeder wrote:

I can't imagine any distributed team would *not* face this issue.

Any other suggestions?

--
Hassan Schroeder ------------------------ hassan.schroeder@gmail.com

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

Aha, that sounds exactly like what I need :slight_smile:

Thanks much!

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 :slight_smile:

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 :slight_smile: