Implement the 'Partial Options Monoid' pattern for the configuration

[chshersh]

This pattern is common in the FP world. The description (in Haskell) can be found here:

• https://medium.com/@jonathangfischoff/the-partial-options-monoid-pattern-31914a71fc67

The idea is the following:

• Create the Options type with all configuration fields optional

• Create functions to create this Options type from different environments:

  • Hardcoded default
  • Environment variables
  • Files
  • CLI options

  It's absolutely okay for different environments to fill only some parts of the config.

• Implement a function to combine two Options with the second argument overriding the previous values if they both are present (otherwise, take the one that is not None)

• Read options on start from all four sources and combine them in the following order of increasing priority (e.g. CLI arguments are more important than everything else)

  1. Defaults.
  2. Environment variables
  3. Configuration file.
  4. CLI flags

That's all! With this approach, it should be possible to configure different options from different sources and have a uniform config.

[crudiedo]

Hi everyone,

I wanted to make sure we have the same variables name format in mind:

Currently, we have 2 different kinds of things we could configure - it's either store_directory\proxy (non tools related) or any tools field.

For non-tools related variables it's quite simple:

# ENV
TOOL_SYNC_STORE_DIRECTORY=~/.bin
# Cli
--store_directory=~/.bin

And for the tools it would be like:

# ENV
TOOL_SYNC_BOTTOM_OWNER=clementtsang
TOOL_SYNC_BOTTOM_REPO=bottom
TOOL_SYNC_BOTTOM_EXE_NAME=btm
TOOL_SYNC_ASSET_NAME_MACOS=darwin
# Cli
--bottom.owner=clementtsang
--bottom.repo=bottom
--bottom.exe_name=btm
--bottom.asset_name.macos=darwin

1. Do we want to use TOOL_SYNC as the env prefix? I thought about just TOOL, but it's quite ambiguous and could be reused by any other tool (:

2. Do we really want to let the ENV configure tools? It looks like parsing that would be a mess (still need to do it for the cli though), and even with some generic parsing function the code will become more complicated.

[chshersh]

@crudiedo Thanks for moving the conversation! Answering your question:

Do we want to use TOOL_SYNC as the env prefix? I thought about just TOOL, but it's quite ambiguous and could be reused by any other tool (:

I agree about the TOOL_SYNC_ prefix for environment variables 👍🏻

Do we really want to let the ENV configure tools? It looks like parsing that would be a mess (still need to do it for the cli though), and even with some generic parsing function the code will become more complicated.

No, we don't environment variables for individual tools 🙂 The usage for environment variables is to apply some configuration for every tool invocation and usually this is some global setting. Tool details are too granular and individual to be supported by env variables (and indeed will be a mess to parse as you mentioned).

My opinion:

Env:

• Config path
• Proxy
• Store directory

CLI args:

• Config path
• Proxy
• Store directory
• Tool details (under separate issue: Support all the fields of the 'ConfigAsset' #91)

File:

• As current