I spent a while debugging this today in an older application. If your settings file contains more 'environments' than your application supports it will fail in every environment in quite an opaque way.
Symptom:
Calling settings.foo fails with
NoMethodError - undefined method `foo' for [ApplicationClass]:Class:
Reproducing:
The following will break settings in every environment, unless the application happens to support an environment called 'default':
default: &default
foo: bar
development:
<<: *default
production:
<<: *default
test:
<<: *default
Solution:
The code is here:
https://github.com/sinatra/sinatra/blob/master/sinatra-contrib/lib/sinatra/config_file.rb#L159
I believe this is actually intended to do the opposite, to check that every environment in the application is covered in the settings file - not that every environment in the settings file is honoured by the application. Even then it could fail more gracefully; for example with an error message to warn the user of missing environments in the settings file or a suitable exception if it's the current environment.
I can code this up over the weekend if it'd be useful. As a bonus it'd allow the functionality seen above, where a common, environment-agnostic set of default settings can be used.
Workaround:
In the mean time you can get around this problem by passing the current environment to settings manually and accessing the information as a hash:
settings.send(settings.environment)['foo']
I spent a while debugging this today in an older application. If your settings file contains more 'environments' than your application supports it will fail in every environment in quite an opaque way.
Symptom:
Calling
settings.foofails withReproducing:
The following will break settings in every environment, unless the application happens to support an environment called 'default':
Solution:
The code is here:
https://github.com/sinatra/sinatra/blob/master/sinatra-contrib/lib/sinatra/config_file.rb#L159
I believe this is actually intended to do the opposite, to check that every environment in the application is covered in the settings file - not that every environment in the settings file is honoured by the application. Even then it could fail more gracefully; for example with an error message to warn the user of missing environments in the settings file or a suitable exception if it's the current environment.
I can code this up over the weekend if it'd be useful. As a bonus it'd allow the functionality seen above, where a common, environment-agnostic set of default settings can be used.
Workaround:
In the mean time you can get around this problem by passing the current environment to settings manually and accessing the information as a hash: