Skip to content

Latest commit

 

History

History
780 lines (527 loc) · 25.5 KB

config.rst

File metadata and controls

780 lines (527 loc) · 25.5 KB
Raw

Configuration Handling

Applications need some kind of configuration. There are different settings you might want to change depending on the application environment like toggling the debug mode, setting the secret key, and other such environment-specific things.

The way Flask is designed usually requires the configuration to be available when the application starts up. You can hard code the configuration in the code, which for many small applications is not actually that bad, but there are better ways.

Independent of how you load your config, there is a config object available which holds the loaded configuration values: The ~flask.Flask.config attribute of the ~flask.Flask object. This is the place where Flask itself puts certain configuration values and also where extensions can put their configuration values. But this is also where you can have your own configuration.

Configuration Basics

The ~flask.Flask.config is actually a subclass of a dictionary and can be modified just like any dictionary:

app = Flask(__name__)
app.config['TESTING'] = True

Certain configuration values are also forwarded to the ~flask.Flask object so you can read and write them from there:

app.testing = True

To update multiple keys at once you can use the dict.update method:

app.config.update(
    TESTING=True,
    SECRET_KEY='192b9bdd22ab9ed4d12e236c78afcb9a393ec15f71bbf5dc987d54727823bcbf'
)

Debug Mode

The DEBUG config value is special because it may behave inconsistently if changed after the app has begun setting up. In order to set debug mode reliably, use the --debug option on the flask command.flask run will use the interactive debugger and reloader by default in debug mode.

$ flask --app hello --debug run

Using the option is recommended. While it is possible to set DEBUG in your config or code, this is strongly discouraged. It can't be read early by the flask command, and some systems or extensions may have already configured themselves based on a previous value.

Builtin Configuration Values

The following configuration values are used internally by Flask:

0.4 LOGGER_NAME

0.5 SERVER_NAME

0.6 MAX_CONTENT_LENGTH

0.7 PROPAGATE_EXCEPTIONS, PRESERVE_CONTEXT_ON_EXCEPTION

0.8 TRAP_BAD_REQUEST_ERRORS, TRAP_HTTP_EXCEPTIONS, APPLICATION_ROOT, SESSION_COOKIE_DOMAIN, SESSION_COOKIE_PATH, SESSION_COOKIE_HTTPONLY, SESSION_COOKIE_SECURE

0.9 PREFERRED_URL_SCHEME

0.10 JSON_AS_ASCII, JSON_SORT_KEYS, JSONIFY_PRETTYPRINT_REGULAR

0.11 SESSION_REFRESH_EACH_REQUEST, TEMPLATES_AUTO_RELOAD, LOGGER_HANDLER_POLICY, EXPLAIN_TEMPLATE_LOADING

1.0 LOGGER_NAME and LOGGER_HANDLER_POLICY were removed. See /logging for information about configuration.

Added ENV to reflect the FLASK_ENV environment variable.

Added SESSION_COOKIE_SAMESITE to control the session cookie's SameSite option.

Added MAX_COOKIE_SIZE to control a warning from Werkzeug.

2.2 Removed PRESERVE_CONTEXT_ON_EXCEPTION.

2.2 JSON_AS_ASCII, JSON_SORT_KEYS, JSONIFY_MIMETYPE, and JSONIFY_PRETTYPRINT_REGULAR will be removed in Flask 2.3. The default app.json provider has equivalent attributes instead.

2.2 ENV will be removed in Flask 2.3. Use --debug instead.

Configuring from Python Files

Configuration becomes more useful if you can store it in a separate file, ideally located outside the actual application package. You can deploy your application, then separately configure it for the specific deployment.

A common pattern is this:

app = Flask(__name__)
app.config.from_object('yourapplication.default_settings')
app.config.from_envvar('YOURAPPLICATION_SETTINGS')

This first loads the configuration from the yourapplication.default_settings module and then overrides the values with the contents of the file the YOURAPPLICATION_SETTINGS environment variable points to. This environment variable can be set in the shell before starting the server:

Bash

$ export YOURAPPLICATION_SETTINGS=/path/to/settings.cfg
$ flask run
 * Running on http://127.0.0.1:5000/

Fish

$ set -x YOURAPPLICATION_SETTINGS /path/to/settings.cfg
$ flask run
 * Running on http://127.0.0.1:5000/

CMD

> set YOURAPPLICATION_SETTINGS=\path\to\settings.cfg
> flask run
 * Running on http://127.0.0.1:5000/

Powershell

> $env:YOURAPPLICATION_SETTINGS = "\path\to\settings.cfg"
> flask run
 * Running on http://127.0.0.1:5000/

The configuration files themselves are actual Python files. Only values in uppercase are actually stored in the config object later on. So make sure to use uppercase letters for your config keys.

Here is an example of a configuration file:

# Example configuration
SECRET_KEY = '192b9bdd22ab9ed4d12e236c78afcb9a393ec15f71bbf5dc987d54727823bcbf'

Make sure to load the configuration very early on, so that extensions have the ability to access the configuration when starting up. There are other methods on the config object as well to load from individual files. For a complete reference, read the ~flask.Config object's documentation.

Configuring from Data Files

It is also possible to load configuration from a file in a format of your choice using ~flask.Config.from_file. For example to load from a TOML file:

import toml
app.config.from_file("config.toml", load=toml.load)

Or from a JSON file:

import json
app.config.from_file("config.json", load=json.load)

Configuring from Environment Variables

In addition to pointing to configuration files using environment variables, you may find it useful (or necessary) to control your configuration values directly from the environment. Flask can be instructed to load all environment variables starting with a specific prefix into the config using ~flask.Config.from_prefixed_env.

Environment variables can be set in the shell before starting the server:

Bash

$ export FLASK_SECRET_KEY="5f352379324c22463451387a0aec5d2f"
$ export FLASK_MAIL_ENABLED=false
$ flask run
 * Running on http://127.0.0.1:5000/

Fish

$ set -x FLASK_SECRET_KEY "5f352379324c22463451387a0aec5d2f"
$ set -x FLASK_MAIL_ENABLED false
$ flask run
 * Running on http://127.0.0.1:5000/

CMD

> set FLASK_SECRET_KEY="5f352379324c22463451387a0aec5d2f"
> set FLASK_MAIL_ENABLED=false
> flask run
 * Running on http://127.0.0.1:5000/

Powershell

> $env:FLASK_SECRET_KEY = "5f352379324c22463451387a0aec5d2f"
> $env:FLASK_MAIL_ENABLED = "false"
> flask run
 * Running on http://127.0.0.1:5000/

The variables can then be loaded and accessed via the config with a key equal to the environment variable name without the prefix i.e.

app.config.from_prefixed_env()
app.config["SECRET_KEY"]  # Is "5f352379324c22463451387a0aec5d2f"

The prefix is FLASK_ by default. This is configurable via the prefix argument of ~flask.Config.from_prefixed_env.

Values will be parsed to attempt to convert them to a more specific type than strings. By default json.loads is used, so any valid JSON value is possible, including lists and dicts. This is configurable via the loads argument of ~flask.Config.from_prefixed_env.

When adding a boolean value with the default JSON parsing, only "true" and "false", lowercase, are valid values. Keep in mind that any non-empty string is considered True by Python.

It is possible to set keys in nested dictionaries by separating the keys with double underscore (__). Any intermediate keys that don't exist on the parent dict will be initialized to an empty dict.

$ export FLASK_MYAPI__credentials__username=user123
app.config["MYAPI"]["credentials"]["username"]  # Is "user123"

On Windows, environment variable keys are always uppercase, therefore the above example would end up as MYAPI__CREDENTIALS__USERNAME.

For even more config loading features, including merging and case-insensitive Windows support, try a dedicated library such as Dynaconf, which includes integration with Flask.

Configuration Best Practices

The downside with the approach mentioned earlier is that it makes testing a little harder. There is no single 100% solution for this problem in general, but there are a couple of things you can keep in mind to improve that experience:

  1. Create your application in a function and register blueprints on it. That way you can create multiple instances of your application with different configurations attached which makes unit testing a lot easier. You can use this to pass in configuration as needed.
  2. Do not write code that needs the configuration at import time. If you limit yourself to request-only accesses to the configuration you can reconfigure the object later on as needed.
  3. Make sure to load the configuration very early on, so that extensions can access the configuration when calling init_app.

Development / Production

Most applications need more than one configuration. There should be at least separate configurations for the production server and the one used during development. The easiest way to handle this is to use a default configuration that is always loaded and part of the version control, and a separate configuration that overrides the values as necessary as mentioned in the example above:

app = Flask(__name__)
app.config.from_object('yourapplication.default_settings')
app.config.from_envvar('YOURAPPLICATION_SETTINGS')

Then you just have to add a separate config.py file and export YOURAPPLICATION_SETTINGS=/path/to/config.py and you are done. However there are alternative ways as well. For example you could use imports or subclassing.

What is very popular in the Django world is to make the import explicit in the config file by adding from yourapplication.default_settings import * to the top of the file and then overriding the changes by hand. You could also inspect an environment variable like YOURAPPLICATION_MODE and set that to production, development etc and import different hard-coded files based on that.

An interesting pattern is also to use classes and inheritance for configuration:

class Config(object):
    TESTING = False

class ProductionConfig(Config):
    DATABASE_URI = 'mysql://user@localhost/foo'

class DevelopmentConfig(Config):
    DATABASE_URI = "sqlite:////tmp/foo.db"

class TestingConfig(Config):
    DATABASE_URI = 'sqlite:///:memory:'
    TESTING = True

To enable such a config you just have to call into ~flask.Config.from_object:

app.config.from_object('configmodule.ProductionConfig')

Note that ~flask.Config.from_object does not instantiate the class object. If you need to instantiate the class, such as to access a property, then you must do so before calling ~flask.Config.from_object:

from configmodule import ProductionConfig
app.config.from_object(ProductionConfig())

# Alternatively, import via string:
from werkzeug.utils import import_string
cfg = import_string('configmodule.ProductionConfig')()
app.config.from_object(cfg)

Instantiating the configuration object allows you to use @property in your configuration classes:

class Config(object):
    """Base config, uses staging database server."""
    TESTING = False
    DB_SERVER = '192.168.1.56'

    @property
    def DATABASE_URI(self):  # Note: all caps
        return f"mysql://user@{self.DB_SERVER}/foo"

class ProductionConfig(Config):
    """Uses production database server."""
    DB_SERVER = '192.168.19.32'

class DevelopmentConfig(Config):
    DB_SERVER = 'localhost'

class TestingConfig(Config):
    DB_SERVER = 'localhost'
    DATABASE_URI = 'sqlite:///:memory:'

There are many different ways and it's up to you how you want to manage your configuration files. However here a list of good recommendations:

  • Keep a default configuration in version control. Either populate the config with this default configuration or import it in your own configuration files before overriding values.
  • Use an environment variable to switch between the configurations. This can be done from outside the Python interpreter and makes development and deployment much easier because you can quickly and easily switch between different configs without having to touch the code at all. If you are working often on different projects you can even create your own script for sourcing that activates a virtualenv and exports the development configuration for you.
  • Use a tool like fabric to push code and configuration separately to the production server(s).

Instance Folders

0.8

Flask 0.8 introduces instance folders. Flask for a long time made it possible to refer to paths relative to the application's folder directly (via Flask.root_path). This was also how many developers loaded configurations stored next to the application. Unfortunately however this only works well if applications are not packages in which case the root path refers to the contents of the package.

With Flask 0.8 a new attribute was introduced: Flask.instance_path. It refers to a new concept called the “instance folder”. The instance folder is designed to not be under version control and be deployment specific. It's the perfect place to drop things that either change at runtime or configuration files.

You can either explicitly provide the path of the instance folder when creating the Flask application or you can let Flask autodetect the instance folder. For explicit configuration use the instance_path parameter:

app = Flask(__name__, instance_path='/path/to/instance/folder')

Please keep in mind that this path must be absolute when provided.

If the instance_path parameter is not provided the following default locations are used:

  • Uninstalled module:

    /myapp.py
/instance

  • Uninstalled package:

    /myapp
    /__init__.py
/instance

  • Installed module or package:

    $PREFIX/lib/pythonX.Y/site-packages/myapp
$PREFIX/var/myapp-instance

    $PREFIX is the prefix of your Python installation. This can be /usr or the path to your virtualenv. You can print the value of sys.prefix to see what the prefix is set to.

Since the config object provided loading of configuration files from relative filenames we made it possible to change the loading via filenames to be relative to the instance path if wanted. The behavior of relative paths in config files can be flipped between “relative to the application root” (the default) to “relative to instance folder” via the instance_relative_config switch to the application constructor:

app = Flask(__name__, instance_relative_config=True)

Here is a full example of how to configure Flask to preload the config from a module and then override the config from a file in the instance folder if it exists:

app = Flask(__name__, instance_relative_config=True)
app.config.from_object('yourapplication.default_settings')
app.config.from_pyfile('application.cfg', silent=True)

The path to the instance folder can be found via the Flask.instance_path. Flask also provides a shortcut to open a file from the instance folder with Flask.open_instance_resource.

Example usage for both:

filename = os.path.join(app.instance_path, 'application.cfg')
with open(filename) as f:
    config = f.read()

# or via open_instance_resource:
with app.open_instance_resource('application.cfg') as f:
    config = f.read()