The Buckblog

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(File.read(railsrc), 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.

environment.rb:

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:

Rails::Initializer.run do |config|
  # [ ... ]

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

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.