Conf loader¶
Python Web Extras is unique in it's simplicity of loading dynamic settings, one of the biggest hurdles of setting up enviroments and configurations of any project that consumes a lot of time.
Table of Contents¶
Automated load conf settings¶
This package also provides a clean way to load your setting in a very django similar fashion.
Example:
# views.py
python_web_extras.fastapi.conf import settings
Although this is very simple, there is a lot going on here. Since these package was based on the simplicity of loading modules (coming from django) we decided to have a similar approach. Let's see:
Django settings module¶
Django by default has a DJANGO_SETTINGS_MODULE where the default is always
the name of the project.settings generated, example myapp.settings.
Dynamically loading¶
Django allows to call the manage.py with different settings with two ways.
- Environment variable:
DJANGO_SETTINGS_MODULE='myapp.development.settings' python manage.py runserver
- Settings property:
python manage.py runserver --settings='myapp.development.settings'
Python Web Extras module¶
The approach is basically the same as django but we called it FASTAPI_SETTINGS_MODULE and it works
exactly the same way when it comes to loading the settings module.
Dynamically loading¶
We prefer the loading of settings via environment variables as we believe it's cleaner.
Example:
# main.py
# Load the settings from the module
from fastapi import FastAPI
python_web_extras.fastapi.conf import settings
# the rest of the logic for the app
app = FastAPI(**settings.fastapi_kwargs)
FASTAPI_SETTINGS_MODULE='core.development.settings' python app.py
The above example is expecting the module location to be passed as a string into
FASTAPI_SETTINGS_MODULE or else it will default to python_web_extras.fastapi.api_settings.
Example¶
An application structure, quite complex and similar to a production ready version.
└── src
├── __init__.py
├── apps
│ ├── __init__.py
│ └── accounts
│ ├── __init__.py
│ ├── models.py
│ └── v1
│ ├── __init__.py
│ ├── routes.py
│ └── views.py
├── core
│ ├── __init__.py
│ ├── configs
│ │ ├── __init__.py
│ │ ├── databases
│ │ │ ├── __init__.py
│ │ │ ├── config.py
│ │ │ ├── routers.py
│ │ │ └── settings.py
│ │ ├── development
│ │ │ ├── __init__.py
│ │ │ ├── local_settings.py
│ │ │ └── settings.py
│ │ ├── settings.py
│ │ ├── testing
│ │ │ ├── __init__.py
│ │ │ └── settings.py
│ │ └── urls.py
└── main.py
The application is split by responsabilities and all the settings live inside a core/configs
module.
core.configs.settings- App settings.core.configs.development.settings- Development settings.core.configs.testing.settings- Testing settings.
Development and testing are inherited from the main settings and therefore there is
no reason to replicate existing configurations and keep the codebase clean.
Dynamically loading¶
Using the example above we want to start the environments with the correct settings.
-
main.pyfile# main.py # Load the settings from the module from fastapi import FastAPI python_web_extras.fastapi.conf import settings # the rest of the logic for the app app = FastAPI(**settings.fastapi_kwargs) -
Start different environtments.
FASTAPI_SETTINGS_MODULE='core.configs.development.settings' src.main # Starts the dev settings FASTAPI_SETTINGS_MODULE='core.configs.testing.settings' src.main # Starts the testing settings FASTAPI_SETTINGS_MODULE='core.configs.settings' src.main # Starts with main settings
python_web_extras.fastapi.conf import settings will know which settings to load by
reading the enviroment variable FASTAPI_SETTINGS_MODULE keeping the code clean and
the configurations separated.
Full working cookiecutter¶
This package is being already used with a similar approach here. A cookiecutter already prepared and designed for business.