Difficulty in adding console module in analytical

[nirvdrum]

This is going way back, but in 2.11.0 the declarative configuration options for :modules and :development_modules were replaced by an environment-based setup in the analytical.yml file. A consequence of this is it's way too hard to log to the console. The console is one of the best things about analytical because I can see what's happening as things get processed. The reason for the difficulty is two-fold:

1. There's no natural configuration for the console. Just adding a key to the analytical.yml file doesn't work because the config parser explicitly looks for hashes. So, something like this won't work:

development:
  console:

But something like this will:

development:
  console:
    garbage: true

This is neither documented nor expected. An explicit configuration line might make more sense, but may break with the backwards-compatible file processor.

2. The next most common way to configure the console is to add it to the :modules list when declaratively configuring analytical. Unfortunately, this now only works if every environment uses the exact same modules. Many providers don't have sandboxes so they must be left out of all environments except production. Since the :development_modules option no longer exists, the lowest common denominator must be used or all modules must be sourced from the configuration file, leading back to the first problem.

It seems unlikely that the change in 2.11 will be rolled back now, as it's been in place for the entire life of the 3.x series. So, feedback on how to deal with this would be appreciated. I'm happy to help out any way I can.

[nirvdrum]

I can pull together a patch if you have a preference on what to do. I think the modules thing is a pretty serious issue in general though. Rather than error out, we could log a warning if the module is in the declarative list but not in the config file, for all but production. But I suppose that runs contrary to the big code change to begin with.

The config file one just needs a design call made on it.

[sfsekaran]

1. Can anyone tell me if this works?:

development:
    console: {}

2. I think logging a warning is good in any case. I don't like the exceptions. If anyone can argue a good point to keep the exceptions around, let me know.

You know--we could send those exceptions to honeybadger or airbrake (this doesn't need to be through any config file, just as a lambda passed into the ruby config so that no further maintenance is needed on exceptions).

Thoughts?