The maze book for programmers!

Algorithms, circle mazes, hex grids, masking, weaving, braiding, 3D and 4D grids, spheres, and more!

DRM-Free Ebook

The Buckblog

assorted ramblings by Jamis Buck

Per-developer configuration

1 February 2007 — 1-minute read

Here’s another trick you can do with your environment.rb file. It’s of dubious value, but if you’re working on a team with conflicting opinions, it might be a handy way to set your own defaults without tyrannically checking them into the team’s source repository.

Just throw the following bit into the bottom of your environment.rb file:

if RAILS_ENV != "production" 
  railsrc = "#{ENV['HOME']}/.railsrc" 
  load(railsrc) if File.exist?(railsrc)

Then, if you put a file named ”.railsrc” in your home directory, your application will look for and load it every time the environment.rb file is loaded (unless you’re in production mode). Your .railsrc might look something like this:

ActiveRecord::Base.colorize_logging = false
# other stuff your apps configure

What other stuff would you put in a per-developer configuration file?

Reader Comments

This would be good for local ActionMailer settings, too.

It would be nice to be able to turn off @verbose test output as described here on a per developer basis. But that doesn’t seem possible.

@Dave Hoover Put something similar (load a file from the home dir) in your rakefile.

I created a personal plugin (acts_as_barnes :) for my customizations so as not to clutter up the app’s environment.rb and rake tasks. I store it in a branches subdir of our svn repo and set a global ignore in my svn config. Easy, out of the way and tailored for me!

per-developer database settings have come up as an annoyance more than once per-developer action mailer config per-developer logging levels could be useful from time-to-time lots of little things

Just create a damn database.yml per developer and dont save it in your repository.

Nice idea! Maybe it would be useful to have the Initializer (“config”) available in the railsrc. So, instead of load(), use:

eval(, binding)

Per-developer settings are not enough. You also need per-app settings.

We use a ~/.rails directory, with separate {app name}-database.yml and {app name}-environment.rb files that get used if present.

And {app name} is specified in the app’s environment.rb just before running the code that looks for the files.

This way you can define all kinds of settings that are developer and application dependent (like database settings, runtime customizations, etc, etc).

I personally think it would be cleaner to simply create custom scripts like ‘username.rb’ in the config dir, and do a non-required include in the environment. That way, you don’t have to go mucking about in your home directory, and changes would only affect the one project. This would be good for permanent personal changes, but I usually don’t have any of those.


if RAILS_ENV != “production” mysrc = ”#{ENV[‘USER’]}.rb” load(mysrc) if File.exist?(mysrc) end

hank.rb (in my case):

ActionController::AbstractRequest.relative_url_root = ”/ralree”

That way, the change is only applied if the current env’s username is ‘hank’. Only problem would be dup usernames. Would be nice for working on multiple machines with multiple checkouts of the code since you’d always have your environment changes committed, and you’d just have to make a properly named account.

Noo Hank! Nooooo!!!

That doesn’t SCALE!!! Why on earth would you want 30 username.rb’s on your config directory? I had a client who had a system like this, where there was a config file for each combination of client, deployment, and environment, and for each developer.

It made me very sad, very often.

I killed it.

It died.

Hank: that’s similar to what I did. In config/environment.rb, I have: do |config|
  # [ ... ]

  # Pull in developer-specific configuration
  user_env = File.join(File.dirname(__FILE__), 'environments', "#{ENV['USER']}.rb")
  eval(, binding, user_env) if File.exists?(user_env) && RAILS_ENV != "production" 

which reads a file in config/environments per-developer, if it exists, in the same context as the other files in there are read.

Timotheo: the advantage of this is that preferences are tracked in subversion across different development machines (eg laptop and desktop in my case).

Timotheo: Well, if I were to scale my projects, I might consider something different. But, usually the max I could have would be 4 developers. Also, why not make a config/developers dir and keep all the configs in there out of the way? I don’t see a problem with this.

mathie: Sounds good. Might implement it now with my new project.