django-split-settings
Organize Django settings into multiple files and directories. Easily override and modify settings. Use wildcards and optional settings files.
Top Related Projects
Reads key-value pairs from a .env file and can set them as environment variables. It helps in developing applications following the 12-factor principles.
Strict separation of config from code.
Django-environ allows you to utilize 12factor inspired environment variables to configure your Django application.
A helper for organizing Django project settings by relying on well established programming patterns.
Quick Overview
Django-split-settings is a utility for organizing Django settings into multiple files and directories. It allows developers to split their Django project's configuration into smaller, more manageable pieces, improving code organization and maintainability.
Pros
- Improves code organization by allowing settings to be split into multiple files
- Enhances maintainability by separating concerns and reducing the size of individual configuration files
- Supports environment-specific settings, making it easier to manage different configurations for development, staging, and production
- Provides a simple and intuitive way to include settings from multiple files
Cons
- Adds a small layer of complexity to the project structure
- Requires careful management to avoid circular imports or conflicting settings
- May slightly increase the initial learning curve for new developers joining the project
- Could potentially lead to scattered settings if not organized properly
Code Examples
- Basic usage in
settings.py
:
from split_settings.tools import optional, include
include(
'components/base.py',
'components/database.py',
optional('local_settings.py')
)
This example includes settings from multiple files, with local_settings.py
being optional.
- Using wildcard imports:
from split_settings.tools import include
include(
'components/base.py',
'components/*.py'
)
This example includes all Python files in the components
directory.
- Environment-specific settings:
from split_settings.tools import include
import os
ENV = os.environ.get('DJANGO_ENV', 'development')
base_settings = [
'components/base.py',
'components/database.py',
'environments/{0}.py'.format(ENV),
]
include(*base_settings)
This example demonstrates how to include environment-specific settings based on an environment variable.
Getting Started
-
Install django-split-settings:
pip install django-split-settings
-
Create a
settings
directory in your Django project. -
Move your existing
settings.py
content intosettings/base.py
. -
Create a new
settings/__init__.py
file with the following content:from split_settings.tools import include include( 'base.py', 'database.py', 'installed_apps.py', optional('local.py') )
-
Update your Django project to use the new settings module:
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'yourproject.settings')
Now your Django settings are split into multiple files, improving organization and maintainability.
Competitor Comparisons
Reads key-value pairs from a .env file and can set them as environment variables. It helps in developing applications following the 12-factor principles.
Pros of python-dotenv
- Language-agnostic: Can be used with any Python project, not limited to Django
- Simpler setup: Requires minimal configuration to get started
- Supports multiple file formats: Can load from .env, .ini, and .yaml files
Cons of python-dotenv
- Less flexible: Primarily focused on environment variables, not general settings management
- Limited scope: Doesn't provide advanced features for organizing complex settings structures
Code Comparison
python-dotenv:
from dotenv import load_dotenv
load_dotenv()
import os
database_url = os.getenv("DATABASE_URL")
django-split-settings:
from split_settings.tools import optional, include
include(
'base.py',
optional('local_settings.py')
)
python-dotenv focuses on loading environment variables from a file, while django-split-settings allows for more complex organization of settings across multiple files. The latter is more suited for large Django projects with intricate configuration needs, while python-dotenv is simpler and more versatile for general Python applications.
Strict separation of config from code.
Pros of python-decouple
- More flexible configuration options, supporting .env files, ini files, and environment variables
- Built-in type casting for configuration values
- Lightweight and easy to use, with minimal dependencies
Cons of python-decouple
- Less focused on Django-specific use cases
- Doesn't provide a built-in mechanism for splitting settings across multiple files
Code Comparison
python-decouple:
from decouple import config
DEBUG = config('DEBUG', default=False, cast=bool)
EMAIL_HOST = config('EMAIL_HOST', default='localhost')
EMAIL_PORT = config('EMAIL_PORT', default=25, cast=int)
django-split-settings:
from split_settings.tools import optional, include
include(
'components/base.py',
'components/database.py',
optional('local_settings.py')
)
While python-decouple focuses on retrieving and casting configuration values from various sources, django-split-settings provides a way to organize and include multiple setting files in a Django project. Both tools serve different purposes and can be used together in a Django project for better configuration management.
Django-environ allows you to utilize 12factor inspired environment variables to configure your Django application.
Pros of django-environ
- Provides a more comprehensive environment variable management solution
- Supports parsing of various data types (e.g., lists, dicts) from environment variables
- Offers built-in integration with popular services like databases and caches
Cons of django-environ
- May introduce additional complexity for simpler projects
- Requires learning a new syntax for environment variable declarations
- Can potentially lead to less explicit configuration management
Code Comparison
django-environ:
import environ
env = environ.Env()
DEBUG = env.bool('DEBUG', default=False)
DATABASES = {
'default': env.db('DATABASE_URL', default='sqlite:///db.sqlite3'),
}
django-split-settings:
from split_settings.tools import optional, include
include(
'components/base.py',
'components/database.py',
optional('local_settings.py')
)
django-environ focuses on environment variable management, while django-split-settings provides a way to organize Django settings into multiple files. django-environ offers more features for handling environment variables, but django-split-settings provides a simpler approach to modularizing settings without introducing new syntax or concepts.
A helper for organizing Django project settings by relying on well established programming patterns.
Pros of django-configurations
- Uses class-based configuration, allowing for inheritance and better organization
- Supports environment-specific settings through class inheritance
- Integrates well with Django's built-in configuration system
Cons of django-configurations
- Requires additional setup and configuration compared to django-split-settings
- May have a steeper learning curve for developers new to class-based configurations
- Less flexibility in organizing settings across multiple files
Code Comparison
django-configurations:
from configurations import Configuration
class Dev(Configuration):
DEBUG = True
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': 'dev.db',
}
}
django-split-settings:
from split_settings.tools import optional, include
include(
'components/base.py',
'components/database.py',
optional('environments/dev.py')
)
Both django-configurations and django-split-settings offer ways to organize Django settings, but they take different approaches. django-configurations uses a class-based system, while django-split-settings focuses on splitting settings into multiple files. The choice between them depends on project requirements and team preferences.
Convert
designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
Organize Django settings into multiple files and directories. Easily override and modify settings. Use wildcards in settings file paths and mark settings files as optional.
Read this blog post for more information. Also, check this example project.
Requirements
While this package will most likely work with the most versions of django
, we officially support:
- 4.2
- 5.0
- 5.1
This package has no dependencies itself.
In case you need older python
/ django
versions support,
then consider using older versions of django-split-settings
.
Installation
pip install django-split-settings
Usage
Replace your existing settings.py
with a list of components that
make up your Django settings. Preferably create a settings package
that contains all the files.
Here's a minimal example:
from split_settings.tools import optional, include
include(
'components/base.py',
'components/database.py',
optional('local_settings.py')
)
In the example, the files base.py
and database.py
are included
in that order from the subdirectory called components/
.
local_settings.py
in the same directory is included if it exists.
Note: The local context is passed on to each file, so each following file can access and modify the settings declared in the previous files.
We also made an in-depth tutorial.
Tips and tricks
You can use wildcards in file paths:
include('components/my_app/*.py')
Note that files are included in the order that glob
returns them,
probably in the same order as what ls -U
would list them. The
files are NOT in alphabetical order.
You can modify common settings in environment settings simply importing them
# local_settings.py
from components.base import INSTALLED_APPS
INSTALLED_APPS += (
'raven.contrib.django.raven_compat',
)
Updating BASE_DIR
The django create-project
command will create a variable in your settings.py
called BASE_DIR
, which is often used to locate static files, media files, and templates.
# Created by django create-project
BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
STATIC_ROOT = os.path.join(BASE_DIR, "staticfiles/")
MEDIA_ROOT = os.path.join(BASE_DIR, "mediafiles/")
The expression for BASE_DIR
means: get the path to the current file (settings.py
), get the parent folder (whatever you named your project), get the parent folder (the root of the project). So STATIC_ROOT
will then be evaluated to /staticfiles
(with /
meaning the root of your project/repo).
With django-split-settings
settings
is now a module (instead of a file), so os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
will evaluate to /whatever-you-named-your-project
as opposed to /
.
To fix this BASE_DIR
needs to be set to the parent folder of /whatever-you-named-your-project
:
BASE_DIR = os.path.dirname(os.path.dirname(os.path.dirname(os.path.abspath(__file__))))
Do you want to contribute?
Read the CONTRIBUTING.md file.
Version history
See CHANGELOG.md file.
Top Related Projects
Reads key-value pairs from a .env file and can set them as environment variables. It helps in developing applications following the 12-factor principles.
Strict separation of config from code.
Django-environ allows you to utilize 12factor inspired environment variables to configure your Django application.
A helper for organizing Django project settings by relying on well established programming patterns.
Convert
designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot