Evaluate proper design for configurations and settings #445
Description
at present, there is some confusion between:
- configuration-based settings (eg generic config, or machine-specific test shots and columns), and
- code-based settings (eg default function arguments).
we should probably design this a bit better with maximum flexibility in mind.
I'm leaning towards making everything config-based, including, eg:
- log setting defaults,
- output setting defaults,
- nickname setting defaults,
most stuff could then be trivially overridden at runtime by dynaconf's env vars logic.
there might still be some complications, so a proper functional analysis is necessary.