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