Regular config file doesn't always take precedence over shared config file.

[tomballgithub]

The 'db-name: setting' in a config file does NOT override the setting within a 'shared' config file. This impacted me after making a setting change and then doing a -cd to clear the database. It cleared the wrong database.

I found this at the following link:
The value set in the regular -cf configuration file takes precedence
https://github.com/RocketMap/RocketMap/blob/develop/docs/first-run/configuration-files.md

However, it doesn't work

Expected Behavior

The -cf configuration file should take precedence over the shared config file.

Current Behavior

The -cf does NOT take precedence over the shared config file for 'db-name'. I have heard this applies to other settings also.

Possible Solution

1. Fix the code so that the -cf settings always take priority
2. Fix the code so that if there are conflicting settings that an error occurs.

Steps to Reproduce (for bugs)

1. Create two databases
2. Assign one to Rocketmap in the shared config file
3. Assign one to Rocketmap in the -cf config file
4. Launch Rocketmap using both a shared and -cf config file
5. See that Rocketmap is using the incorrect database, the shared one

Context

Your Environment

• Version used:
• Environment name and version (e.g. Python 2.7):
• Operating System and version (desktop or mobile):

[sebastienvercammen]

Updated title to reflect that this isn't about db-name specifically. The order of priority for config items doesn't seem to be consistent for all items: some get precedence, others don't, and CLI arg priority (-cf vs -scf) might affect it as well.

Since we've defined the shared config file as a config file for the ConfigArgParse library, the load order isn't controlled by us.

To be investigated.

[pogo-excalibur]

Logic summary from ConfigArgParse (quick examination):

1. Read command line args
2. Read ENV variables
   • unless they're already set, in which case they get ignored
3. Read config files (marked is_config_file=True) in reverse order to the order that they are declared in
   • unless they're already set, in which case they get ignored
4. Fill in any required but missing args with their default values

I'd guess that it's the combination of reversing the order and ignoring already set args that's caused the issue here.

In summary, ConfigArgParse doesn't appear to allow args to be overridden.

Quick addendum: there are subtleties here around some arg types - for example store_true and store_false are only considered 'set' if they are set to True or False respectively, i.e. if a store_true arg gets set to False in one config file it can still get set to True by another config file higher in the load order.

[sebastienvercammen]

@pogo-excalibur Thanks for looking into the details.

Tagged as "bug" since we describe a specific load order in our documentation (config should have precedence over shared config).