You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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']
The text was updated successfully, but these errors were encountered:
JonMidhir
changed the title
ConfigFile could fail
ConfigFile: settings.foo fails when settings file contains too many environments
Jan 27, 2017
JonMidhir
changed the title
ConfigFile: settings.foo fails when settings file contains too many environments
ConfigFile: settings.foo fails when settings file contains non-implemented environments
Jan 28, 2017
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 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:
The text was updated successfully, but these errors were encountered: