flask-bones
flask-bones copied to clipboard
cburmeister
Broaden configuration options for Flask
Enables a relative instance directory, which prevents config and other artifacts from being dropped in he app/ folder with source code.
Add supports for loading config from instance/app.cfg or from arbitrary file pointed to by CONFIG_FILE environment variable.
Does this have an advantage over setting SERVER_NAME (for example) in your environment?
Not specifically for SERVER_NAME or the other settings that are configured to read from environment variables, but customizing one of the flags that aren't read from environment (e.g. POSTGRES_DB) or introducing new config parameters is currently not possible without altering the codebase (at minimum, in serve.py or in a WSGI wrapper).
The support for pyfile or envvar make it trivial to override or introduce new config options at runtime with no changes to the app code. This could be particularly useful in a container setup with distributed config management, where the container would pull down the desired config from centralized source at runtime.
I'm completely open to allowing all configuration options to be read from the environment.
With that said -- I think I would like to keep the entire application configuration there.
I usually maintain an .env file in my projects that I source before a deploy. You can even hook this into docker-compose if you're into that sort of thing.
That's fair -- to dynamically load any config key from the environment we'll need to pick some prefix, tomorrow I can work on changes to swap out the file-based configs from 209f3ec for a base class that reads any environment variable prefixed with FLASK_ and sets the corresponding instance variable in the config class, then we can inherit from that and provide the defaults as done in config.py today.
Heh, no need to reinvent the wheel here: brettlangdon/flask-env. I'll setup APP_ as the prefix instead of FLASK_ as the prefix to avoid confusion about what's for flask or used by the flask app.
Do you intend to maintain compatibility with Python2? If so I will also add a dependency on the future module: http://python-future.org/compatible_idioms.html#metaclasses