@steven_ferguson the reason it requires
container.lookupFactory is because the config is just a simple POJO singleton, but isn't registered as such (i.e. it doesn't register with the
instantiate: false option).
When you call
container.lookup('foo:bar'), it assumes that the
foo/bar module will contain a "class" and it will try to instantiate that class. When that fails (in this case, because 'config/environment' turns out to be a POJO, not an
Ember.Object), it fails with the error message you saw.
It looks the config is pulled via a simple resolver lookup by filepath - nothing actually explicitly registers the config AFAIK. This could be considered a bug, perhaps, but I know there are rumblings of a significant overhaul of the CLI's approach to config coming down the pipe.
@rwjblue could you comment on that? Is it worth submitting a PR to somehow register the config as a singleton, or should we just hold off for the rumored config overhaul?