On 04May2019 09:02, DL Neil <pythonl...@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 <c...@cskk.id.au>
--
https://mail.python.org/mailman/listinfo/python-list
