Skip to content

ConfigFile: settings.foo fails when settings file contains non-implemented environments #1243

@JonMidhir

Description

@JonMidhir

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']

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions