Override configuration through CLI

[shtlrs]

Many CLIs allow loading configuration from a path or environment, but they also do allow overriding some values thanks to options.

This could be an improvement to the currently available CLI by adding the possibility to override any configuration by specifiying it as an option.

For example, suppose we have configured the database_uri in our config file or environment, if I wanted to override it, I could do

pinnwand http --database_uri='/connection/string'

This gives more flexibility to users when they just want to test a particular thing with the cli.

Implementation

I'm not sure of what click offers for such things, but the naive way would be to add as many decorators as options, but that would bloat everything up.

Another raw idea (not sure of feasibility), is to dynamically lookup the configuration module's attributes, and make decorators of these. We probably loose all the typing information though :/

[supakeen]

As you've probably seen in #229 as well the way pinnwand does configuration is naive and not very good. It'd be nice to maybe upgrade this issue a bit to find a new approach to all of the configuration options pinnwand currently has, which would be through the environment, a .env file (after #229 lands), and with this issue included as separate command line arguments.

I'll go have a look around at how other projects manage this sort of thing as well.

[shtlrs]

As you've probably seen in #229 as well the way pinnwand does configuration is naive and not very good. It'd be nice to maybe upgrade this issue a bit to find a new approach to all of the configuration options pinnwand currently has, which would be through the environment, a .env file (after #229 lands), and with this issue included as separate command line arguments.

I'll go have a look around at how other projects manage this sort of thing as well.

Indeed, i mostly needed this when testing the server with specific configuration without too much shenanigans to modify files and risk race conditions and whatnot.

I'll also have a look at how other projects tackle such a challenge and see what can be done about this.

[shtlrs]

I've made a quick github code search

And I've found a lot of projects that favored explicitness over black magic by just stacking up options.

I have an idea to make this dynamically for which i'll make a POC if you'd like, but i think since we only have about 12 configs & it's not susceptible towards changing anytime soon, it wouldn't be so bad to stack them up.

[shtlrs]

I've put more thoughts into this, and I think I like the approach of stacking them up better.

The fact that we're going to define a way to define and load them up dynamically introduces a lot of problems

1. Developing and maintaining the datastructure to represnt the different options that will later be loaded adds more complexity.
2. Whatever datastructure will be decided, its evolution needs to be easy, which i'm a bit iffy about.
3. This will most probably affect readability greatly, especially in the command callback as we'd lose info such as the order of the options, their names & types and would have to resort to sometype of reflection to access/retrieve them.

Since we're grouping everything down the main command group, we won't have much knowledge duplication, so we'd be good as far as the DRY principle goes.

Also, we won't necessarily allow overriding all of our configs, as it wouldn't make much sense to override the footer for example from the cli, etc. So we could just define what we'd allow overriding from the cli for now, and if people want more granular control, then can do so from the environment or the config file.