On 28Jun2019 09:34, Alan Gauld <alan.ga...@yahoo.co.uk> wrote:
Environment variable have fallen out of favour for user settings and config files are now preferred. But some things are a bit easier via en environment variable - especially where you spawn new sub-processes and don't want the sub-process to have to re-read the config file each time.
This is something of a simplification. Most programmes consult a few places for configuration information.
A programme may want to run in different ways (different places to write files, different language settings or timezones, etc). Environment variables are a convenient and inheritable way to indicate a specific way to run, because they get inherited (as a copy) from parent programme to child programmes and so on.
So a flask application will usually be invoked from within a web server, and various things about how it should run _may_ be indicated by environment variables set by the web server.
A flexible programme may decide how to run from several places, in a specific order (to ensure predictable controllable behaviour).
A normal order would be: command line arguments, environment variables, personal config file ($HOME/.thingrc), system configfile (/etc/thingrc), inbuilt defaults within the programme.
The idea here is that this is a simple hierachy of defaults. Anything can be overridden by a command line option. If not supplied, an environment variable may be consulted. Otherwise the personal config file. Otherwise the system default. Otherwise some default within the programme.
Programmatically you don't go: for each setting, look at these things in the order above. Instead you has some "settings" structure in the programme, initially filled out with some internal defaults. You read the system file to override the builtin defaults. Then you read the personal file to override that. Then you consult the environment to override that. Then you process the command line and have it override various things. A single pass across all this stuff. Any of it may be missing.
Returning to Flask and the environment: because a Flask app is often invoked from within a web server instead of directly, it isn't feasible to pass it "command line" arguments to control it. So the environment becomes the most convenient place for ad hoc special settings.
Cheers, Cameron Simpson <c...@cskk.id.au> "How do you know I'm Mad?" asked Alice. "You must be," said the Cat, "or you wouldn't have come here." _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
