It's bad practice to put code in settings.py
other than assignments. It's better suited as a management command:
from django.core.management.base import BaseCommand
from django.core.cache import cache
class Command(BaseCommand):
def handle(self, *args, **kwargs):
cache.clear()
self.stdout.write('Cleared cache\n')
Which you can add to your project by sticking it in someapp/management/commands
. For instance you could create a new app called utils
and add that to your INSTALLED_APPS
and the directory structure would look like this:
utils
├── __init__.py
└── management
├── __init__.py
└── commands
├── __init__.py
└── clearcache.py
You can now clear cache by doing ./manage.py clearcache
. If you want to run clearcache every time you runserver you can just write a shell alias to do that:
alias runserver='./manage.py clearcache && ./manage.py runserver'
Alternately I think you can write it as a stand-alone script and configure the settings it requires by hand:
from django.conf import settings
# obviously change CACHES to your settings
CACHES = {
'default': {
'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
'LOCATION': 'unique-snowflake'
}
}
settings.configure(CACHES=CACHES) # include any other settings you might need
from django.core.cache import cache
cache.clear()
Writing your stand-alone script like this will prevent circular imports, and allow you to import it from your settings.py. Although there is no guarantee that settings.py will be imported only once, so in general I'd avoid this. It'd be nice if the signal framework could fire off an event once every time the app is started, after settings are loaded for stuff like this.
runit
in production to start/stop cherrypy. In that case, your suggestion would not work. I want the solution to be usable for different setups. – Spirited