Merb configuration options in rails3

Hey all,

I've used Rails v1 for a little while before switching to Merb, then coming back again for rails3. While using merb, I got really comfortable using the config files to store configuration directives that I wouldn't need to type at the command line when starting up instances:

config/init.rb: ... Merb::Config.use do |c|   ...   c[:adapter] = :thin   c[:port] = 1234   ... end

As much fun as it is to type "rails s thin -p 1234", I'd rather just use "rails s", or even "merb". I've spent hours digging through google and various documentation projects trying to figure this out, how can I do this in rails3?

Thanks.

arai wrote:

As much fun as it is to type "rails s thin -p 1234", I'd rather just use "rails s", or even "merb". I've spent hours digging through google and various documentation projects trying to figure this out, how can I do this in rails3?

Add to ~/.profile (or similar):

While your alias suggestion is cute, it's not exactly what I had in mind.

My organization has a dev server that runs nginx on port 80 and reverse proxies to multiple merb and rails instances at higher ports (100XX) on the same box. Not all of these instances are always running at the same time, but we can have more than one active at any given time, and we map vhosts to ports via nginx (test.com is passed to 127.0.0.1:10023 for instance).

With merb, one of our techs can spin up an instance with a simple command (merb) from the project's directory and we're good. With rails, we need to know which port corresponds to which project and it requires a different command for each project we run, as well as mentioning thin.

I understand that there are options that exist outside of rails that will allow me to sort of do this from the command line with one simple command (even ones that won't break our merb projects), my question is why rails3, an advertised fusion of rails and merb, didn't borrow that good idea from merb and doesn't support this sort of configuration directive from it's files.

To put it another way, we're more than happy to patch this in and push it upstream, but not if it's just going to get rejected by the core team.

Thanks