This app provides a baseclass to easily realize AppSettings for any django project. The advantage of using an AppSettings class lies in the possibility for the programmer to assign default values for settings if the setting is not present in the main settings.py
- Django >= 2.2
-
Install django-pluggableappsettings
- From the pip repository:
pip install django-pluggableappsettings
- or directly from github:
pip install git+git://github.com/NB-Dev/django-pluggableappsettings.git
- From the pip repository:
-
Create your AppSettings class in any of your project's files. E.g. in 'app_settings.py'.
-
Define your settings by setting the class attributes as one of the provided settings types
from django_pluggableappsettings import AppSettings, Setting class MyAppSettings(AppSettings): MY_SETTING = Setting('DEFAULT_VALUE')
-
Access the setting from anywhere:
from app_settings import MyAppSettings setting = MyAppSettings.MY_SETTING
Different setting types are provided with the package:
The most basic setting that looks up the setting's value from the settings.py
usually the attribute name is used for
the detection. If, however, the settings_name
parameter is given, this name is used instead for the lookup in the
settings.py
. It simply returns the value from the settings.py or, if that is not set, the default value.
If no default value is provided and the setting is not set in your settings.py, an AttributeError
is thrown.
Also a list of aliases can be passed to allow for multiple names of one setting (e.g. for backwards compatibility)
Checks whether the value is callable and calls it once before returning. Subsequent accesses to this setting return the
cached return value of the first call. If force_callable
is True
, the setting throws a ValueError
if the value of
the setting is not callable.
Checks whether the value is callable. If so, the callable is called each time when the setting is
accessed. If force_callable
is True
, the setting throws a ValueError
if the value of the setting is not callable.
Behaves as a Setting but accepts only Classes or dotted paths to classes as values. If the value is a dotted path, the path is translated to a class before returning, so the returned value is always a class.
Accepts only values that are of type int or can be casted to type int
Accepts only values of type float of values that can be casted to type float
Accepts only strings as value
Makes sure that the value is an iterable
A class that checks whether the given value is of a certain type and optionally allows casting the value to that type. Used as a base class for all type checking classes and can be easily subclassed to allow checking of various value types.
To create your own type checking setting simply subclass this type and set the class attributes _setting_type
and _cast_value
according to your needs. The _setting_type
attribute specifies the desired type while the
_cast_value
attribute specifies whether the value should be casted to the _setting_type
. A _cast_value
of True
essentially results in a call of value = _setting_type(value)
.
E.g. The IntSetting
is defined as follows:
class IntSetting(TypedSetting):
"""
An integer setting
"""
_setting_type = int
_cast_value = True
If you need more elaborate casting functions, you can overwrite the cast_value(self, value)
function
of your type which should return the casted value.
You can access any setting by simply importing your AppSettings class and accessing the corresponding attribute.
The package provides a convenient override_appsettings
decorator / context manager to allow for the temporary
override of AppSettings values. It is used just like Django's override_settings
decorator but with an extra argument:
The AppSettings-Class that is to be altered has to be passed in as first argument. Following should be keyword, value
arguments where the keyword is the name of the setting to be overridden and the value is the desired return value.
E.g.:
from django_pluggableappsettings.test.utils import override_appsettings
from myapp.appsettings import MyAppSettings
class SomeTestCase(TestCase):
@override_appsettings(MyAppSettings, SETTING='new_value')
def test_decorated(self):
MyAppSettings.SETTING # This returns 'new_value'
def test_context_manager(self):
with override_appsettings(MyAppSettings, SETTING='new_value'):
MyAppSettings.SETTING # This returns 'new_value'
The included tests can be run standalone by running the tests/runtests.py
script. You need to have Django and
mock installed for them to run. If you also want to run coverage, you need to install it before running the tests
- Fixes deprectated location of "Iterable" in collections module to make this project Python 3.10 compatible. Thank you @kocunop for the pull request.
- Move to github actions for testing
- Removing support for old Python and Django Versions that are no longer officially supported. I did not actually change the codebase but removed the tests while moving to github actions.
- Added tests for deprecation warnings, to catch those problems ahead of time in the future.
- If a setting is not defined on the
AppSettings
object, it is now retrieved fromdjango.conf.settings
if it is available there. This makes it possible to use theAppSettings
as a drop-in replacement fordjango.conf.settings
. Thank you @mkay849 for the pull request.
- Moving to a Readme.md did not work for pypi... now it should be though.
- Breaking Change: Dropping Support for Python 2. Results in a dropping of support for Django 1.x.
- Addings Upport for Django 2.1, 2.2 and 3.0
- Fixing the README to be correctly displayed on pypi
- Version bump as I forgot to convert the readme. Added a publish.py to automate publishing in future.
- Adding tests for Django 1.10 and 1.11.
- Adding the possibility to look for a settings value under a different name in the
settings.py
by usage of thesettings_name
parameter - Fixing a bug that caused all
AppSettings
instances to share the same cache of loaded settings. This could cause the settings to be overridden by other settings
- Adding an
override_appsettings
decorator / context manager to allow the overriding of AppSettings values in test - Added the possibility to retrieve non-
Setting
attributes from theAppSettings
class to allow for custom attributes or custom functions.
- I screwed up with pypi and need to bump the version number - Sorry
-
Changing structure of Setting class to being able to add repeatedly called functions as setting.
Warning: This breaks compatibility of custom settings classes. To fix this, simply rename the
get
method of your custom classes to_get
-
Added a
CalledEachTimeSetting
that takes a callable that is called each time the setting's value is accessed -
Renamed the
CallableSetting
toCalledOnceSetting
to make the differentiation to theCalledEachTimeSetting
clearer. The old name will stay as an alias for now. -
The
CalledEachTimeSetting
and theCalledOnceSetting
take anforce_callable
kwarg to set whether the value of the setting is enforced to be callable or not.
- Releasing first stable version
- Added 'aliases' parameter to
Setting
to allow multiple names for one setting (e.g. for backwards compatibility)
- Extended code to also work with Python 3
- Added
TypedSetting
Setting type which allows for the setting to be typechecked - Added
IntSetting
,FloatSetting
,StringSetting
andÌterableSetting``` as subtypes of ```TypedSetting
- Added the changelog
- Redesign of settings to allow different types of settings that can now also provide type checking.
- Settings are now explicitly defined and no
_DEFAULT_
prefix is needed anymore - Also no staticmethod decorator is needed anymore
- Allow the easy definition of multiple allowed setting types so that a setting could e.g. accept either string or an Integer
- Allow the chaining of callables with typed settings to check that the return value of a callable is of the correct type
This Project is maintaned by Mactory