This is how a typical config/environments/*.rb
file begins:
MyApp::Application.configure do
config.cache_classes = false
...
end
The block passed to configure
dereferences the symbol config
which is apparently unbound. How does this technically work? The symbols used in a block/Proc/lambda should be bound in the context of its declaration, not left to be resolved in the dynamic scope at the call site.
A related question is, where exactly is the Application.configure
method declared? It's not in either application.rb
, engine.rb
, or railtie.rb
. Maybe if I managed to find this method, I would have found the answer to my main question.
Also related, I have studied the Rails initialization procedure in excruciating detail, and I can't find even a mention of a config/environments/*.rb
file. If I knew how these files were treated by the init procedure, that may shed some light on this.
It's a method config
in Rails::Application
in the railties gem in lib/rails/application.rb
which returns an instance of Application::Configuration
, defined in lib/rails/application/configuration.rb
.
The method configure
is contributed to Railtie
from the autoload
ed module Configurable
, lib/rails/railtie/configurable
, and is defined as
def configure(&block)
class_eval(&block)
end
which explains why the block that configure
accepts can resolve the config
symbol. Note that class_eval
is another piece of rubyist magic that makes this work: it rebinds the passed-in block's self
symbol to the call site's class.
Check the comments in the first file in the Booting Process section, which explains where, how and in what order all this goodness comes from, including how the /config/environments
directory is processed.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With