#3207 A config file received on the command line should replace the system config
Closed 3 years ago by mikem. Opened 3 years ago by fredlefebvre.
https://github.com/fred-lefebvre/koji.git master  into  master

config file on the command line should replace the system config
fredlef • 3 years ago  
koji/__init__.py
file modified
+7 -6
@@ -1974,12 +1974,7 @@

      result = config_defaults.copy()

  

      # note: later config files override earlier ones

- 

-     # /etc/koji.conf.d

-     configs = ['/etc/koji.conf.d']

- 

-     # /etc/koji.conf

-     configs.append('/etc/koji.conf')

+     configs = []

  

      # User specific configuration

      if user_config:
@@ -1987,6 +1982,12 @@

          # The existence will be checked

          configs.append((os.path.expanduser(user_config), True))

      else:

+         # /etc/koji.conf.d

+         configs.append('/etc/koji.conf.d')

+ 

+         # /etc/koji.conf

+         configs.append('/etc/koji.conf')

+ 

          # User config dir

          configs.append(os.path.expanduser("~/.koji/config.d"))

          # User config file

no initial comment

Koji client config files are additive. That makes sense when loading the system config, followed by /etc/koji.d/* and user configs unders ~/. But when a user config is provided on the command line, it should be loaded instead of the system config and not in addition to it. Otherwise the system config can never be fully overridden.

:thumbsup:

Great work creating a PR from GitHub

tracking issue #3209 I think it is okish behaviour. Nevertheless, it is not backward-compatible. @mikem @julian8628 thoughts?

it is not backward-compatible

Indeed. I would rather solve the issue without breaking compatibility.

The config given on the command line replaces the user config, not the system config. However, the user config takes precedence since it is read last, so you can override any of the system settings. The thing you can't do, b/c of limitations in ConfigParser, is unset a value or set a value to None.

Do you recall the specific situation that prompted this?

Likely, handling this in a backwards-compatible way will mean adding a new option. Perhaps a flag that disables reading the system config (analogous to the --noprofile option in bash).

Another, more complicated, approach might be to provide a way for subsequent configs to unset values.

@fredlefebvre any reply to the above? In particular, I'd be interested to see a specific example of the problem

closing this and #3209. Feel free to reopen #3209 if you want to continue the discussion

Pull-Request has been closed by mikem

3 years ago
Metadata