Configuration confusion = Friday Filosofical Finking

[DL Neil]

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?


Apologies: as they say in football, this is a game of two halves...


1
In the same way that functions and methods are controlled by 
parameters/arguments, so are scripts. Whether the code we are building 
will be long-running, eg a server or web-app; or perhaps it will be run 
on numerous occasions but for shorter periods, by the same or different 
users; we (usually) need to configure settings to control or customise 
its use. Here are some categories of config-data:

- k: CONSTANTS or variable_constants
- keys: API keys
- credentials: DB configurations
- logs: log definitions
- coding: DEBUG
- 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

(please add better examples and missing categories)


2
Python offers a veritable range of mechanisms to accomplish 
configuration tasks. Some are easier to see (literally), whereas others 
are less visible. Some are easier to access and amend. Some allow for 
more complex data-relationships. Others limited to Python-coders only. 
Each has its own virtue, and possibly disadvantage. Here's a list:

- mainline*
- (import-ed) code module
- application .conf/.ini/etc file
- user-controlled .conf/.ini/etc file
- command-line
- (OpSys) environment variable

(please add anything missing - together with how you might (not) use it)

* old-time terminology?
This is the script/program-file executed by the python3 command, called 
from WSGI, or whatever. Thus, config-data appearing shortly-after the 
import statements (per PEP-8) or soon after the if __main__ etc construct.


Aside
It might be easier to imagine the two lists side-by-side - you may 
recall from primary/elementary school such question-structures, eg a 
list of animals on one side and another of collective-nouns on the 
other. The task was to pair "lion" with "pride" and "sheep" with 
"flock", etc. We even have mechanised grading for this style of 
question, even though most computer-assessment is the multi-choice 
a/b/c/d question. Grrr!


So, to the question(s)
How do you pair various categories of data, with particular mechanisms? 
Do you separate config-data by mechanism or lump-it-all-in-together? Is 
it merely a preference, or even a habit, eg I've some utility code 
close-to-hand? Are some mechanisms too inherently-weak for use in 
certain situations? Is there too much "risk" if a mechanism can't be 
included in version-control? Dare we allow users certain tools? (see 
also previous thread discussing users and .ini/.yaml/etc files) Do some 
not offer the necessary power/flexibility?


Web-Refs:
Python Setup and Usage https://docs.python.org/3/using/index.html
PEP-8 https://www.python.org/dev/peps/pep-0008/

Zen of Python references (import this):
Explicit is better than implicit.
There should be one-- and preferably only one --obvious way to do it.

-- 
Regards,
=dn