Yet Another App Settings for Django
Project description
Yet Another App Settings - manage settings for your reusable app
Project site: http://radiac.net/projects/django-yaa-settings/
Source code: https://github.com/radiac/django-yaa-settings
Features
Easy to install and use
Provide defaults and validate user settings before use
Works with Django’s settings overrides in tests
Supports Django 2.2 to 3.1 on Python 3.5 to 3.8.
Version 1.0.0 was the last version to support earlier versions of Django.
Installation
Install from pip:
pip install django-yaa-settings
Usage
In your app, create a local app_settings.py:
from yaa_settings import AppSettings class MySettings(AppSettings): prefix = 'MYAPP' # Can be overridden in Django settings as MYAPP_ATTRIBUTE ATTRIBUTE = 'a static value defined at class creation' @property def PROPERTY(self): """ Return a value calculated whenever it is accessed Can be overridden in Django settings as MYAPP_PROPERTY """ return 'a value calculated when accessed' def CALLABLE(self, value): """ Always called, passed the MYAPP_CALLABLE value from Django settings (or passed None if that is not defined) """ if value is None: raise ValueError('MYAPP_CALLABLE must be configured') return value
Import and subclass AppSettings
Only define one AppSettings subclass per file
Set the prefix attribute if you want to give your settings a prefix in Django’s settings.
Settings should be uppercase for consistency with main Django settings.
Now you can access your app’s settings directly on the class, without the prefix:
from . import app_settings def some_method(request): if app_settings.ATTRIBUTE == 1: return app_settings.PROPERTY return app_settings.CALLABLE
You can override these settings in your main Django settings, using the prefix:
MYAPP_ATTRIBUTE = 'value available as app_settings.ATTRIBUTE' MYAPP_PROPERTY = 'value available as app_settings.PROPERTY' MYAPP_CALLABLE = 'value passed to MySettings.CALLABLE'
Why?
Use the prefix to namespace your settings
It’s always a good idea to namespace your settings based on your app’s name to avoid collisions with other apps. By using the prefix attribute you can omit the prefix throughout your app, making your code neater.
The prefix is optional and you can manually namespace your settings if you’d prefer the consistency of using the same full setting throughout your project.
Namespace settings while retaining test support
Using the prefix mimicks the simpler settings.py that you find in some projects:
from django.conf import settings SETTING = getattr(settings, 'MYAPP_SETTINGS', 'default')
but unlike that simpler pattern, Yaa-Settings still works with standard setting overrides for tests - see the Django documentation for more details.
Create dynamic defaults using properties
A property on your AppSettings subclass will be evaluated every time you access it, unless you override it in Django’s settings. This allows you to generate dynamic defaults at runtime.
Validate or standardise settings using methods
A method on your AppSettings subclass will be called every time you access it, and will be passed the value you have defined in Django’s settings. This allows you to validate settings, or process them ready for use.
Changelog
1.1.0, 2020-07-22: Moved supported Django to 2.2 to 3.1 (#1, #2 - thanks to clinoge)
1.0.0, 2018-06-24: Released as stable
0.1.0, 2018-06-24: Initial release
Project details
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Hashes for django-yaa-settings-1.1.0.tar.gz
Algorithm | Hash digest | |
---|---|---|
SHA256 | 7cd3e7fdb4cf632394dd3872734bb92dd3de4394ddc760fa8a2d33cc645e4971 |
|
MD5 | ccc01214749e4844863530f2814f62db |
|
BLAKE2b-256 | 3e62215259ab49a5c4877b6c966c10a7270f93a3501e3f5aeed034d823d03c30 |