Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow packaged resources and alternate extensions #195

Open
bckohan opened this issue Jun 12, 2020 · 0 comments
Open

Allow packaged resources and alternate extensions #195

bckohan opened this issue Jun 12, 2020 · 0 comments

Comments

@bckohan
Copy link
Contributor

bckohan commented Jun 12, 2020

Thanks for a great utility. It's kept my Django settings sane for a few years now.

I manage several large Django projects with many apps that are deployed in multiple settings, each time having a different INSTALLED_APP stack. A pattern I've found immensely useful in this scenario is for my constituent app packages to include default settings files as packaged resources. I give them alternate extensions (i.e. .conf instead of .py) so my system knows which ones to automagically include.

I've been using an extended version of django-split-settings to accomplish this, but I think others could find this useful as well so I'm happy to submit my extensions as a PR.

For example, the idea is to be able to include packaged resources where your directory structure looks like:

mypackage
├── __init__.py
└── settings
    ├── __init__.py
    └── base.conf

As so:

from split_settings import include, resource, optional
from mypackage import settings

include(
    resource(settings, 'base.conf'),
    resource('mypackage.settings', 'base.conf'),  # alternate
    optional(resource(settings, 'local.conf')),  # optional can wrap resources too
)

Another nicety about using an alternate to .py for your settings files is that its a visual cue to other devs (and your IDE) that these files may not behave like typical python files on account of how split-settings sets their scope.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant