Exporting¶
When¶
Exports occur before the logging.config yaml files are needed. There are two process types: worker and app
When an app is run, it exports the app logging configuration.
Right before a multiprocessing.pool.Pool runs, it exports
the worker logging configuration.
Right before a thread or ThreadPool runs, G’d and Darwin sit down to decide which calamity will befall you. Best to avoid that cuz Python logging module is thread-safe. Changes to the logging.config in one thread affects them all and those changes last as long as the app runs.
Safe means safe to remove you from the gene pool. Would be a great name for a horror movie. Don’t be in that movie.
Where / what¶
Export location (on linux): $HOME/.local/share/[package name]/
This is xdg user data dir and the configuration is per package. Python logging configurations’ cascade!
Whats exported?
one for the app
At least one, for the multiprocessing workers
If a user|coder edits and makes a change, undo’ing those changes would be considered quite rude, minimally, poor ettiquette.
So that gauntlets stay on and package authors live long fulfilling peaceful uneventful lives, overwrite existing logging config yaml files never happens. Although fully capable, just absolutely refuses to do so!
If confident no changes have been made, can manually delete (unlink).
There will be no need for gauntlets, can safely put those away.
Upgrade path¶
How to upgrade a particular logging.config yaml file?
Best to increment the version and switch the code base to use the latest version
Custom changes should be upstreamed.
Preferred the previous version
There currently isn’t a means to change which logging.config yaml file a package uses.
This sounds like a job for user preference database, gschema. Not yet implemented
