Override default config

[Tattoo]

Currently, Oxygen knows what handlers are available through the config.yml file located within the project.

Devise a way for user to give their own config file. Consider following things:

• Since config is always used when Oxygen runs, it would be nice if you could override config.yml once permanently
• Lesser concern is being able to override default config once
• Should it be part of CLI? Consider how it would make most sense given the other CLI arguments are arbitrary
  • eg. python -m oxygen --config myconfig.yml arbitaryhandler --config arbitaryconfig.yml is messy

[Tattoo]

An idea

• We provide --add-config, --clear-config, and --print-config
  • --add-config would take a path to file and include that content to config.yml
  • --clear-config would copy config.yml over with golden_config.yml that is part of the installation
  • --print-config would pretty-print the current content of config.yml
• If we want to also offer library keywords for these, they should probably be part of OxygenCore (but then again, the current config logic is already there)
  • Do we need to transform the OxygenLibrary into RF hybrid library?

Pros

• This is nicer than what is described in the OG description
  • The problem with forcing end user to give it all the time is that once a user has single custom handler, then they will always need to give the argument => constant extra work

Cons

• "What my config even is?"

[vrchmvgx]

When you say --add-config is included, do you mean that it updates base config on a key-by-key basis or just replaces it altogether? The former could be more powerful but unless there's real use cases for it, the simplicity/predictably of a clean replace would probably be preferred.

As for the other two, my questions are:

• In which case would we need to explicitly declare --clear-config, or could that be implicit by not specifying a config at all? Or do you mean that the user is able to maintain their own template in a known path, as well?
• Does --print-config need to be explicit, or would it be better to log that by default unless a --quiet or similar is passed to Oxygen?

As for using a hybrid library, I think it could make the design neater if we used a hybrid approach for both Oxygen and the sub-libraries (which would avoid things like using getattr to run functions, something that feels just a little off) but then the concern remains the development experience for the end user.

[Tattoo]

my idea was that --add-config would be pure append:

# config.yml
my_config:
    foo: bar

# my_config.yml
my_config:
    foo: baz
another_config:
    cux: corgi

$ python -m oxygen --add-config my_config.yml

will result in:

# config.yml

my_config:
    foo: bar
my_config:
    foo: baz
another_config:
    cux: corgi

I already checked that if multiple same keys are given, only the last one will be in effect when parsed (in the other words, my_config.foo == 'baz')

The other ideas are nice as well, they solve the problem of polluting the CLI

[Tattoo]

Talked yesterday with @kjkaizens who pointed out that the config could be validated (valid yaml, can import handlers) everytime config is touched. This should lessen the confusion around appending

[Tattoo]

In which case would we need to explicitly declare --clear-config, or could that be implicit by not specifying a config at all? Or do you mean that the user is able to maintain their own template in a known path, as well?

Regarding this, after a bit of experimentation it's clear we need config reset to be separate, explicit option. In a case where --add-config would be called on command line where the value is coming from a variable:

$ python -m oxygen --add-config ${MY_CONFIG}

If then the env var is not defined then it evaluates to empty string, the call is in fact:

$ python -m oxygen --add-config

and you would, instead of adding, resetting your config -- super confusing.