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
--
https://mail.python.org/mailman/listinfo/python-list
