# Providing more generic settings module

**URL:** <https://forum.djangoproject.com/t/providing-more-generic-settings-module/40435>\
**Category:** Getting Started\
**Created:** [April 16, 2025, 5:55am UTC](https://forum.djangoproject.com/t/providing-more-generic-settings-module/40435 "2025-04-16T05:55:31Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![atharva](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/atharva/32/28107_2.png) [@atharva](https://forum.djangoproject.com/u/atharva)\
**Post date:** [April 16, 2025, 5:55am UTC](https://forum.djangoproject.com/t/providing-more-generic-settings-module/40435/1 "2025-04-16T05:55:31Z")

</div>

Can we create a more generic `django.conf.LazySettings` object? I am creating some settings or configuration file (not really related to Django project) but inside my django codebase. But similar to `django.conf.settings` there will be some default values and some overridden values. Now this part can be achieved in many ways, but can we provide a native way through Django? Below is my expected behavior:

```python
# app_default_settings.py
RUNTIME = "myapp.runtimes.DefaultRuntime"
LOAD_TARGET = "myapp.targets.DBTarget"

# app_settings.py
RUNTIME = "<overridden value>"
LOAD_TARGET = "<overridden value>"

# myapp/conf.py (maybe)
app_settings = GenericSettings(settings_mod="myapp.app_settings",
                               default_mod="myapp.app_default_settings")

# target usage
from myapp.conf import settings

use(settings.RUNTIME)

```

---

<div class="post-metadata">

**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\
**Post date:** [April 16, 2025, 12:12pm UTC](https://forum.djangoproject.com/t/providing-more-generic-settings-module/40435/2 "2025-04-16T12:12:40Z")

</div>

Welcome @atharva !

[A settings file is just a Python module.](https://docs.djangoproject.com/en/5.2/topics/settings/#the-basics)

> It can import values from other settings files.

This means that you can import a “base” or “default” settings file and only override the differences.

e.g. In `settings.py`:

```auto
import app_default_settings
import app_settings

... and other variables as necessary ...

```

(If this is not clear or does not appear to address the issue, please post a more complete description of what you’re trying to do.)

---

<div class="post-metadata">

**Author:** ![atharva](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/atharva/32/28107_2.png) [@atharva](https://forum.djangoproject.com/u/atharva)\
**Post date:** [April 17, 2025, 5:46am UTC](https://forum.djangoproject.com/t/providing-more-generic-settings-module/40435/3 "2025-04-17T05:46:31Z")

</div>

Thanks for the response Ken!  
But Django’s settings internally uses LazySettings, which also internally uses Settings class. Now a case may come where I don’t want to import `django.conf.settings` object and use custom settings as I mentioned in my example. For some reasons, `Settings` class uses `global_settings` module implicitly, that contains all default settings. Can we modify this part to make it extensible for other users?

---

<div class="post-metadata">

**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\
**Post date:** [April 17, 2025, 11:31am UTC](https://forum.djangoproject.com/t/providing-more-generic-settings-module/40435/4 "2025-04-17T11:31:07Z")

</div>

I’m sorry, I’m not seeing where the current behavior is in any way a problem or limitation.

You can always override a default setting.

Please provide a _real_ example, with a description of the use case and the code necessary to create the problem, of where the current `Settings` class and behavior creates a problem or limitation.

> [@atharva](#):
>
> Now a case may come where I don’t want to import `django.conf.settings` object and use custom settings as I mentioned in my example.

In the absence of a real and identified issue, apply [the YAGNI principle](https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it)