Inconsistent with Catalyst - CATALYST_CONFIG

[Altreus]

Catalyst will use CATALYST_CONFIG as well as ${NAME}_CONFIG; and if it is set, it will also look for the _local file next to it.

Setting CATALYST_CONFIG has no effect on Config::ZOMG, and setting env_lookup didn't seem to achieve the desired effect.

my $c = Config::ZOMG->new( env_lookup => 'CATALYST_CONFIG' )->load;
use Data::Dump; dd $c;
{}

What did work was to set name => "Catalyst", but then of course, ${NAME}_CONFIG no longer works with the original value of name.

use Config::ZOMG;
my $c = Config::ZOMG->new( name => "Catalyst" )->load;
use Data::Dump; dd $c;

do {
  my $a = {
  #snip

I have been using CATALYST_CONFIG exclusively in all of our Docker environments so I don't have to know which specific variable I have to override in each container; but any process using Config::ZOMG to avoid loading the entire Catalyst application therefore cannot find the config without hijinks.

[frioux]

CATALYST_CONFIG has never been documented to work with this module; that's working as intended. env_lookup does seem at least poorly documented; would happily take patches to fix that. If you need something that more closely emulated Catalyst you might look at Config::JFDI or catalyst itself.

[Altreus]

Config::JFDI also ignored CATALYST_CONFIG

Any method of getting it to look at CATALYST_CONFIG while also acknowledging the _local file next to it would be fine - using name => "Catalyst" seems hacky at best

[frioux]

Why?

[Altreus]

Because the app isn't called Catalyst and there's not much point in having a config loader that works like Catalyst if I have to jump through hoops to make it work like Catalyst.

If the Catalyst app will look for ${NAME}_CONFIG and CATALYST_CONFIG, and load _local files appropriate to them, then I don't gain anything from using Config::JFDI or Config::ZOMG if the same environment doesn't have the same effect. I am better off just loading the whole Catalyst application, and in that case what is Config::ZOMG even for?

[frioux]

It's faster and the whole point is that it's not catalyst. I personally believe that the catalyst config mechanism is fundamentally flawed and that storing the config of your templating engine (which is likely to never change) next to your database connect string (which is very likely to change) is ridiculous. If you want this to act like catalyst you'll need to tell it to; sorry :)

[Altreus]

But I can't seem to tell it to, that's my point. None of the available constructor options had it look at both CATALYST_CONFIG as well as ${NAME}_CONFIG.

[frioux]

Yeah I hear you. Want comaint? 😉

…

-- Sent from a rotary phone rented from Ma Bell

On Thu, Aug 9, 2018, 7:59 AM Alastair Douglas ***@***.***> wrote: But I can't seem to tell it to, that's my point. None of the available constructor options had it look at both CATALYST_CONFIG as well as ${NAME}_CONFIG. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAf43Eh__zhcVEhy12D1FXvRVPvhm1jks5uPE5KgaJpZM4V1x8T> .

[Altreus]

I don't think I'm in a position to make that decision ;)

I can put a PR together though :)