Configuration confusion = Friday Filosofical Finking

[Cameron Simpson]

On 04May2019 09:02, DL Neil <PythonList at DancesWithMice.info> wrote:
>When configuring an application, which mechanisms do you [not] use for 
>setting particular operating-parameters, and/or do you *only* utilise 
>a particular method to initialise certain categories of 
>configuration-data?
[...]

I don't conventions with have complete coverage of your list, but:

>Here are some categories of config-data:
>
>- k: CONSTANTS or variable_constants

I like programmes to be able to run without a configuration file. Aside 
from API keys and other credentials, I like both modules and main 
programmes to have reasonable wired in default CONSTANTS for when there 
is no external configuration. Even for a database I might at least 
provide something like:

  DEFAULT_DBHOST = '127.0.0.1'

to expect a local database server if there's no configuration.

>- keys: API keys
>- credentials: DB configurations

Keys and credentials are always in separate files, and _not_ under 
revision control. At least not under the same control as the code - they 
should never leak into a code repo.

However, the location of those files might be configurable. pArticularly 
when the application can be invoked from the command line it is often 
desirable to be able to say "get your configuration from over there".

>- logs: log definitions

I believe the logging module supports putting logging configuration in a 
file; I haven't used it.

>- coding: DEBUG

Usually default off (so that production mode is the default, reducing 
accidents), triggerable by setting the environment variable $DEBUG to 
"1".  And the logging configuration might specific log levels.

>- ops: userID (in the sense of addressing, billing, or control)
>- limitations: environment (eg only runs under *nix or MS-Windows)
>- user: personalID, user-category, credentials, 2FA

Userids tend to go in configuration so that one can run an instance of 
the application for this purpose, and and also for that purpose.

Regarding mechanisms, my hierarchy of configuration tends to go:

  code default CONSTANTS
  configuration file
  environment variables
  command line options

in order of override. Not all things get control from all levels. In 
particular security related modes _might_ not pay attention to any 
environment variables, and might even mandate explicit settings in a 
config file. To avoid accidents and assumptions.

For flattish configuration I do like the .ini file format: it is very 
easy to read and edit. The situation is articularly good now that 
Python3's parser supports both easy dictionary/mapping access to the 
fields and also will write out such a mapping in .ini format, which is 
great for generating configurations (example: the "init" step for a new 
app: it can dump the entire config out to the standard place if there's 
no existing config file, giving the user a prefilled file with all the 
setting available for inspection and adjustment).

Cheers,
Cameron Simpson <cs at cskk.id.au>