Wanted to discuss how configs work

[Altreus]

I'm having a hard time with configs at the moment because of the interactions between module configs, package configs and the app configs.

I'll omit all the boring details and jump to my conclusion - I think it would be good if configs worked in a similar way to classes. The core of the problem I was having was that there was no way to refer to the "core" config while adding some peripheral configs into it.

My options are basically to overwrite or not to overwrite, and Fuel makes the decision whether to merge or not.

This decision is consistent so I don't have a problem with it, but it would be useful if within a config I could refer to a specific other config file and draw the values from there.

return [
    'actually_override' => [ 'custom', 'values' ],
    'reimport_from_package' => \Config::get('explicit_package_name::reimport_from_package');
];

This way, if I am loading a module's config and overwriting a package's config with it (or merging, whatever), then I can explicitly avoid an awkward loop of discovery and loading by drawing my values directly from the package's config.

I likened this to classes because it is similar to the way you can always refer to \Fuel\Core\Classname, thereby being able to extend this class with a new class, which is picked up when the generic name is asked for.

[WanWizard]

The config architecture of FuelPHPis based on the premise that there is only one config with a given name, application wide.

This config file has it's base in app/config. core/config only contains defaults, for values that REQUIRE a value, to avoid the framework generating errors because you forgot to define a required key in your app config file. Core configs should not be touched, they should be considered as part of the framework.

An app config can be extended in both a module, a core config in a package. A package is considered a core extension, so like with the core, any config file in a package should only contain defaults, and should not be considered by the application.

A module is part of the application, and therefor has a config file that can be accessed explicitly. Without the explicit module name, the app/config file is addressed. These are the only two under application control, so there is no explicit access required to the other ones.

So if you find yourself in need of accessing a package or core config file explicitly, from a framework point of view you're doing something wrong.

[Altreus]

Right, I guess that makes sense. I could instantiate the package with the configs rather than have the package fetch the configs, but I was thinking of configs in terms of classes like I suggested, i.e. there's the main config for a thing, peripheral configs that add to it, and the generic name for it which is how you access the dynamic content of the config after all merging and stuff has been applied.

I got this idea basically from the fact that you can choose to merge or override a config - but my conclusion is admittedly not the only interpretation of that situation.

[WanWizard]

Since we haven't decided yet how to deal with configs in the 2.0 architecture, it is absolutely an interesting discussion to have.

I've thought about a real OO approach, but you quickly get into trouble with "what extends what", since the sequence that works for you and your app might not work for me (which is the issue you now have with the way configs are processed).

Perhaps it would be an interesting idea to work on this a bit more. In 2.0, we use collection objects to store data instead of array's, it might be worth while to see if that could be extended, for example with custom setters/getters which could also do parameter validation.

Another option is to work more event driven. Instead of pulling data in, an "item" could register it has config of a certain time or name, which when a load request comes in, all registered config items could be called to collect all data. It would also save a lot of file system searching, since you directly access only what is registered.

As 2.0 will have no distinction between packages and modules anymore (i.e. a module will get a bootstrap), you already have a central place where the available configs could be registered.

[WanWizard]

p.s. I'll be around in two weeks time, perhaps we can find some time (and a table and a few pints) to discuss it? Maybe others have some ideas of how to progress too?

[Altreus]

Propeller concurs. Propeller will always concur with beer.

[WanWizard]

This is where we currently are with regards to config: https://github.com/fuelphp/config

[willsteinmetz]

I'm hoping this is related, but while my company is still working with Fuel < 2.0, we need to make use of modules. I can successfully load a module config file and that works fine. The part I'm stuck on and having trouble finding information about is how to override it in the fuel/app/config directory.

I've tried dropping the file just in that directory as well as creating a directory under that with the same name as my module and putting the config file in there. Neither of those works.

Is it even possible to have overrides for module configs? If so, how does one do that and can the documentation on the site be updated to show that?

[WanWizard]

Short answer is, you can't. Module config files have a higher priority in the merge order then app config files.

Long answer: If you dump $paths in the Finder class, line 358 (in 1.8/develop), you'll see exactly which paths are searched, and in which other.

You can inject the path to APP in front of this list using Finder::instance()->flash(APPPATH.'config'.DS), and remove it again using Finder::instance()->clear_flash().