Django: ImproperlyConfigured: ustawienie SECRET_KEY nie może być puste

102

Próbuję skonfigurować wiele plików ustawień (programowanie, produkcja, ...), które zawierają niektóre ustawienia podstawowe. Nie może się jednak udać. Kiedy próbuję uruchomić ./manage.py runserver, pojawia się następujący błąd:

(cb)clime@den /srv/www/cb $ ./manage.py runserver
ImproperlyConfigured: The SECRET_KEY setting must not be empty.

Oto mój moduł ustawień:

(cb)clime@den /srv/www/cb/cb/settings $ ll
total 24
-rw-rw-r--. 1 clime clime 8230 Oct  2 02:56 base.py
-rw-rw-r--. 1 clime clime  489 Oct  2 03:09 development.py
-rw-rw-r--. 1 clime clime   24 Oct  2 02:34 __init__.py
-rw-rw-r--. 1 clime clime  471 Oct  2 02:51 production.py

Ustawienia podstawowe (zawierają SECRET_KEY):

(cb)clime@den /srv/www/cb/cb/settings $ cat base.py:
# Django base settings for cb project.

import django.conf.global_settings as defaults

DEBUG = False
TEMPLATE_DEBUG = False

INTERNAL_IPS = ('127.0.0.1',)

ADMINS = (
    ('clime', '[email protected]'),
)

MANAGERS = ADMINS

DATABASES = {
    'default': {
        #'ENGINE': 'django.db.backends.postgresql_psycopg2', # Add 'postgresql_psycopg2', 'mysql', 'sqlite3' or 'oracle'.
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'cwu',                   # Or path to database file if using sqlite3.
        'USER': 'clime',                 # Not used with sqlite3.
        'PASSWORD': '',                  # Not used with sqlite3.
        'HOST': '',                      # Set to empty string for localhost. Not used with sqlite3.
        'PORT': '',                      # Set to empty string for default. Not used with sqlite3.
    }
}

# Local time zone for this installation. Choices can be found here:
# http://en.wikipedia.org/wiki/List_of_tz_zones_by_name
# although not all choices may be available on all operating systems.
# In a Windows environment this must be set to your system time zone.
TIME_ZONE = 'Europe/Prague'

# Language code for this installation. All choices can be found here:
# http://www.i18nguy.com/unicode/language-identifiers.html
LANGUAGE_CODE = 'en-us'

SITE_ID = 1

# If you set this to False, Django will make some optimizations so as not
# to load the internationalization machinery.
USE_I18N = False

# If you set this to False, Django will not format dates, numbers and
# calendars according to the current locale.
USE_L10N = False # TODO: make this true and accustom date time input

DATE_INPUT_FORMATS = defaults.DATE_INPUT_FORMATS + ('%d %b %y', '%d %b, %y') # + ('25 Oct 13', '25 Oct, 13')

# If you set this to False, Django will not use timezone-aware datetimes.
USE_TZ = True

# Absolute filesystem path to the directory that will hold user-uploaded files.
# Example: "/home/media/media.lawrence.com/media/"
MEDIA_ROOT = '/srv/www/cb/media'

# URL that handles the media served from MEDIA_ROOT. Make sure to use a
# trailing slash.
# Examples: "http://media.lawrence.com/media/", "http://example.com/media/"
MEDIA_URL = '/media/'

# Absolute path to the directory static files should be collected to.
# Don't put anything in this directory yourself; store your static files
# in apps' "static/" subdirectories and in STATICFILES_DIRS.
# Example: "/home/media/media.lawrence.com/static/"
STATIC_ROOT = '/srv/www/cb/static'

# URL prefix for static files.
# Example: "http://media.lawrence.com/static/"
STATIC_URL = '/static/'

# Additional locations of static files
STATICFILES_DIRS = (
    # Put strings here, like "/home/html/static" or "C:/www/django/static".
    # Always use forward slashes, even on Windows.
    # Don't forget to use absolute paths, not relative paths.
)

# List of finder classes that know how to find static files in
# various locations.
STATICFILES_FINDERS = (
    'django.contrib.staticfiles.finders.FileSystemFinder',
    'django.contrib.staticfiles.finders.AppDirectoriesFinder',
#    'django.contrib.staticfiles.finders.DefaultStorageFinder',
)

# Make this unique, and don't share it with anybody.
SECRET_KEY = '8lu*6g0lg)9z!ba+a$ehk)xt)x%rxgb$i1&022shmi1jcgihb*'

# List of callables that know how to import templates from various sources.
TEMPLATE_LOADERS = (
    'django.template.loaders.filesystem.Loader',
    'django.template.loaders.app_directories.Loader',
#     'django.template.loaders.eggs.Loader',
)

TEMPLATE_CONTEXT_PROCESSORS = (
    'django.contrib.auth.context_processors.auth',
    'django.core.context_processors.request',
    'django.core.context_processors.debug',
    'django.core.context_processors.i18n',
    'django.core.context_processors.media',
    'django.core.context_processors.static',
    'django.core.context_processors.tz',
    'django.contrib.messages.context_processors.messages',
    'web.context.inbox',
    'web.context.base',
    'web.context.main_search',
    'web.context.enums',
)

MIDDLEWARE_CLASSES = (
    'django.middleware.common.CommonMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'watson.middleware.SearchContextMiddleware',
    'debug_toolbar.middleware.DebugToolbarMiddleware',
    'middleware.UserMemberMiddleware',
    'middleware.ProfilerMiddleware',
    'middleware.VaryOnAcceptMiddleware',
    # Uncomment the next line for simple clickjacking protection:
    # 'django.middleware.clickjacking.XFrameOptionsMiddleware',
)

ROOT_URLCONF = 'cb.urls'

# Python dotted path to the WSGI application used by Django's runserver.
WSGI_APPLICATION = 'cb.wsgi.application'

TEMPLATE_DIRS = (
    # Put strings here, like "/home/html/django_templates" or "C:/www/django/templates".
    # Always use forward slashes, even on Windows.
    # Don't forget to use absolute paths, not relative paths.
    '/srv/www/cb/web/templates',
    '/srv/www/cb/templates',
)

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'south',
    'grappelli', # must be before admin
    'django.contrib.admin',
    'django.contrib.admindocs',
    'endless_pagination',
    'debug_toolbar',
    'djangoratings',
    'watson',
    'web',
)

AUTH_USER_MODEL = 'web.User'

# A sample logging configuration. The only tangible logging
# performed by this configuration is to send an email to
# the site admins on every HTTP 500 error when DEBUG=False.
# See http://docs.djangoproject.com/en/dev/topics/logging for
# more details on how to customize your logging configuration.
LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'filters': {
        'require_debug_false': {
            '()': 'django.utils.log.RequireDebugFalse'
        }
    },
    'formatters': {
        'standard': {
            'format' : "[%(asctime)s] %(levelname)s [%(name)s:%(lineno)s] %(message)s",
            'datefmt' : "%d/%b/%Y %H:%M:%S"
        },
    },
    'handlers': {
        'mail_admins': {
            'level': 'ERROR',
            'filters': ['require_debug_false'],
            'class': 'django.utils.log.AdminEmailHandler'
        },
        'null': {
            'level':'DEBUG',
            'class':'django.utils.log.NullHandler',
        },
        'logfile': {
            'level':'DEBUG',
            'class':'logging.handlers.RotatingFileHandler',
            'filename': "/srv/www/cb/logs/application.log",
            'maxBytes': 50000,
            'backupCount': 2,
            'formatter': 'standard',
        },
        'console':{
            'level':'INFO',
            'class':'logging.StreamHandler',
            'formatter': 'standard'
        },
    },
    'loggers': {
        'django.request': {
            'handlers': ['mail_admins'],
            'level': 'ERROR',
            'propagate': True,
        },
        'django': {
            'handlers':['console'],
            'propagate': True,
            'level':'WARN',
        },
        'django.db.backends': {
            'handlers': ['console'],
            'level': 'DEBUG',
            'propagate': False,
        },
        'web': {
            'handlers': ['console', 'logfile'],
            'level': 'DEBUG',
        },
    },
}

LOGIN_URL = 'login'
LOGOUT_URL = 'logout'

#ENDLESS_PAGINATION_LOADING = """
#    <img src="/static/web/img/preloader.gif" alt="loading" style="margin:auto"/>
#"""
ENDLESS_PAGINATION_LOADING = """
    <div class="spinner small" style="margin:auto">
        <div class="block_1 spinner_block small"></div>
        <div class="block_2 spinner_block small"></div>
        <div class="block_3 spinner_block small"></div>
    </div>
"""

DEBUG_TOOLBAR_CONFIG = {
    'INTERCEPT_REDIRECTS': False,
}

import django.template.loader
django.template.loader.add_to_builtins('web.templatetags.cb_tags')
django.template.loader.add_to_builtins('web.templatetags.tag_library')

WATSON_POSTGRESQL_SEARCH_CONFIG = 'public.english_nostop'

Jeden z plików ustawień:

(cb)clime@den /srv/www/cb/cb/settings $ cat development.py 
from base import *

DEBUG = True
TEMPLATE_DEBUG = True

ALLOWED_HOSTS = ['127.0.0.1', '31.31.78.149']

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'cwu',
        'USER': 'clime',
        'PASSWORD': '',
        'HOST': '',
        'PORT': '',
    }
}

MEDIA_ROOT = '/srv/www/cb/media/'

STATIC_ROOT = '/srv/www/cb/static/'

TEMPLATE_DIRS = (
    '/srv/www/cb/web/templates',
    '/srv/www/cb/templates',
)

Kod w manage.py:

(cb)clime@den /srv/www/cb $ cat manage.py 
#!/usr/bin/env python
import os
import sys

if __name__ == "__main__":
    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "cb.settings.development")

    from django.core.management import execute_from_command_line

    execute_from_command_line(sys.argv)

Jeśli dodam from base import *do /srv/www/cb/cb/settings/__init__.py(który w przeciwnym razie jest pusty), magicznie zaczyna działać, ale nie rozumiem dlaczego. Ktoś mógłby mi wytłumaczyć, co się tutaj dzieje? To musi być jakaś magia modułów Pythona.

EDYCJA: Wszystko również zaczyna działać, jeśli usunę tę linię z base.py

django.template.loader.add_to_builtins('web.templatetags.cb_tags')

Jeśli usunę tę linię z web.templatetags.cb_tags, to również zacznie działać:

from endless_pagination.templatetags import endless

Wydaje mi się, że to dlatego, że ostatecznie prowadzi do 

from django.conf import settings
PER_PAGE = getattr(settings, 'ENDLESS_PAGINATION_PER_PAGE', 10)

Więc tworzy dziwne okrągłe rzeczy i gra się kończy.

python django settings klimat
źródło
Dokładnie, w końcu zawsze będziesz potrzebować ustawień, nawet jeśli pochodzą one z django.conf
Guilherme David da Costa
2
Spróbuj zmienić swój DJANGO_SETTINGS_MODULE na settings.development
Guilherme David da Costa
Każdy, kto używa virutalenvwrapper, wypróbuj odpowiedź crimeminister na stackoverflow.com/questions/10738919/ ...
lukeaus

Odpowiedzi:

109

Miałem ten sam błąd i okazało się, że jest to cykliczna zależność między modułem lub klasą załadowaną przez ustawienia a samym modułem ustawień. W moim przypadku była to klasa oprogramowania pośredniego, która została nazwana w ustawieniach, które same próbowały załadować ustawienia.

Sam Svenbjorgchristiensensen
źródło
4
Tak, myślę, że kołowość to robi.
klimat
5
Refaktoryzuj, aby uniknąć zależności cyklicznych. Dokładne rozwiązanie jest naprawdę dość specyficzne dla twojego własnego kodu.
Sam Svenbjorgchristiensensen
6
Wskazówka: aby zidentyfikować przyczynę problemu, np. Dodaj losową instrukcję drukowania w pliku ustawień i przesuń ją, aby zobaczyć, gdzie się psuje.
Felix Böhme
17
Nie znalazłem odpowiedzi na to.
Avinash Raj
8
Ta odpowiedź byłaby bardziej przydatna, gdyby była bardziej szczegółowa… mówi, że problem polega na „czymś”.
Hack-R
74

Napotkałem ten sam problem po zmianie ustawień zgodnie z instrukcjami z książki Daniela Greenfielda Dwie miarki Django .

Rozwiązałem problem, ustawiając 

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "project_name.settings.local")

w manage.pyi wsgi.py.

Aktualizacja:

W powyższym rozwiązaniu localnazwa pliku (settings / local.py) znajduje się w moim folderze ustawień, który zawiera ustawienia dla mojego środowiska lokalnego.

Innym sposobem rozwiązania tego problemu jest zachowanie wszystkich typowych ustawień w settings / base.py, a następnie utworzenie 3 oddzielnych plików ustawień dla środowisk produkcyjnych, pomostowych i deweloperskich.

Twój folder ustawień będzie wyglądał następująco:

settings/
    __init__.py
    base.py
    local.py
    prod.py
    stage.py

i zachowaj następujący kod w swoim settings/__init__.py

from .base import *

env_name = os.getenv('ENV_NAME', 'local')

if env_name == 'prod':
    from .prod import *
elif env_name == 'stage':
    from .stage import *
else:
    from .local import *
Jinesh
źródło
Dla każdego, kto używa Pliszki na PythonAnywhere, po prostu dodaj „.dev”. na końcu tej linii w WSGI ... os.environ ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings.dev' później będziesz musiał utworzyć local.py poza repozytorium źródeł dla haseł itp.
Inyoka
Powinna być najlepsza odpowiedź
Dev
ImportError: Żaden moduł o nazwie local
Dheeraj M Pai
@Tessaracter użyj nazwy pliku ustawień, którego używasz zamiast local. W moim przypadku ustawienia lokalne zostały zachowane w pliku settings / local.py
Jinesh
2
To narusza konwencje Django, zastępując odpowiednio udokumentowaną DJANGO_SETTINGS_MODULEnową niestandardową zmienną środowiskową, która nie jest obsługiwana po wyjęciu z pudełka i musi być obsługiwana ręcznie. Dziwię się, że ma to tak wiele pozytywnych opinii. Pracuję nad projektem z taką konfiguracją i napotykamy wiele problemów, od trudności w skonfigurowaniu izolowanego środowiska do lokalnego rozwoju po zerwanie bibliotek zewnętrznych, ponieważ oczekują, że DJANGO_SETTINGS_MODULEbędą działać zgodnie z oczekiwaniami, a tak nie jest.
Ariel
21

Miałem ten sam błąd z python manage.py runserver.

U mnie okazało się, że przyczyną był nieaktualny skompilowany plik binarny (.pyc). Po usunięciu wszystkich takich plików w moim projekcie, serwer znowu zaczął działać. :)

Więc jeśli pojawi się ten błąd, znikąd, tj. Bez dokonywania jakichkolwiek zmian pozornie związanych z ustawieniami django, może to być dobry pierwszy środek.

akshay
źródło
2
dzięki za tę wskazówkę. Miałem identyczny problem na moim serwerze deweloperskim. Usunięcie wszystkich plików .pyc z folderu projektu załatwiło sprawę. Edytowałem plik settings.py tuż przed tym.
krokodyl
15

Usuń pliki .pyc

Polecenie terminala Ubuntu do usuwania pliku .pyc: find . -name "*.pyc" -exec rm -rf {} \;

Mam ten sam błąd, kiedy zrobiłem Python manage.py runerver. To dlatego, że plik .pyc. Usunąłem plik .pyc z katalogu projektu, a następnie działał.

Aslam Khan
źródło
3
find . -type f -name *.pyc -deletezrobi
Srinivas Reddy Thatiparthy
8

Nie określiłem pliku ustawień:

python manage.py runserver --settings=my_project.settings.develop
maugsburger
źródło
6

Zaczyna działać, ponieważ na base.py masz wszystkie potrzebne informacje w pliku podstawowych ustawień. Potrzebujesz linii:

SECRET_KEY = '8lu*6g0lg)9z!ba+a$ehk)xt)x%rxgb$i1&amp;022shmi1jcgihb*'

Więc to działa, a kiedy to zrobisz from base import *, importuje SECRET_KEY do twojego development.py.

Przed wprowadzeniem jakichkolwiek ustawień niestandardowych należy zawsze importować podstawowe ustawienia.

EDYCJA: Ponadto, gdy django importuje programowanie z twojego pakietu, inicjalizuje wszystkie zmienne wewnątrz bazy, ponieważ zdefiniowałeś w from base import *środku__init__.py

Guilherme David da Costa
źródło
przepraszam, nie rozumiem. Na początku development.py znajdował się import z bazy * i nie działał.
klimat
Przepraszam, wskoczyłem bez względu na to, co się naprawdę działo. Django wciąż próbuje zaimportować ustawienia z settings zamiast z development.py, ponieważ wydaje się, że powodem pracy podczas importowania bazy w init .py
Guilherme David da Costa
5

Myślę, że to błąd środowiska , powinieneś spróbować ustawić:DJANGO_SETTINGS_MODULE='correctly_settings'

吾 慎行
źródło
4

Miałem ten sam problem z Selerem. Moje ustawienia.py przed :

SECRET_KEY = os.environ.get('DJANGO_SECRET_KEY')

po:

SECRET_KEY = os.environ.get('DJANGO_SECRET_KEY', <YOUR developing key>)

Jeśli zmienne środowiskowe nie są zdefiniowane, to: SECRET_KEY = TWÓJ klucz programistyczny

MrNinjamannn
źródło
4

W init .py katalogu settings zapisz poprawny import, na przykład:

from Project.settings.base import *

Nie ma potrzeby zmiany wsgi.py ani manage.py

szeptacz
źródło
Idealny! Dzięki.
Mayur
3

Rozwiązałem ten problem występujący na OS X z Django zarówno w wersji 1.5, jak i 1.6, dezaktywując wszystkie aktywne sesje w virtualenv i uruchamiając go ponownie.

andilabs
źródło
2

Aby wrzucić inne potencjalne rozwiązanie do miksu, miałem settingsfolder, a także settings.pyw moim projekcie reż. (Wróciłem z plików ustawień opartych na środowisku do jednego pliku. Od tego czasu ponownie przemyślałem.)

Python był zdezorientowany, czy chcę zaimportować, project/settings.pyczy project/settings/__init__.py. Usunąłem settingskatalog i teraz wszystko działa dobrze.

Brendan Quinn
źródło
2

Dla każdego, kto używa PyCharm: zielony przycisk „Uruchom wybraną konfigurację” spowodowałby ten błąd, ale uruchomiono następujące działania:

py manage.py runserver 127.0.0.1:8000 --settings=app_name.settings.development

Aby to naprawić, musisz edytować zmienne środowiskowe konfiguracji. Aby to zrobić, kliknij menu rozwijane „Wybierz konfigurację uruchamiania / debugowania” po lewej stronie zielonego przycisku uruchamiania, a następnie kliknij opcję „edytuj konfigurację”. Na karcie „środowisko” zmień zmienną środowiskową DJANGO_SETTINGS_MODULEna app_name.settings.development.

Jamie Williams
źródło
1

Chciałem tylko dodać, że otrzymałem ten błąd, gdy nazwa mojej bazy danych została źle wpisana w moim settings.pypliku, więc nie można utworzyć bazy danych .

Lexo
źródło
1

Rozwiązałem ten problem w wersji 1.8.4, naprawiając ustawienia SZABLONÓW, które zawierały literówkę (usunięcie TEMPLATES ['debug'] rozwiązało to)

Przejrzyj ustawienia, które ostatnio zmieniłeś, upewnij się, że wszystkie klawisze są z książki.

oriadam
źródło
0

Rozwiązałem ten problem, usuwając spacje wokół znaków równości ( =) w moim .envpliku.

aiven
źródło
0

W moim przypadku problem był - miałem swoje app_folderiw settings.pynim. Wtedy zdecydowałem się wejść do Settings folderśrodka app_folder- i to się zderzyło settings.py. Po prostu zmieniłem nazwę Settings folder- i wszystko działało.

Chiefir
źródło
0

Mój Mac OS nie spodobał się, że nie znalazł zmiennej env ustawionej w pliku ustawień:

# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = os.environ.get('MY_SERVER_ENV_VAR_NAME')

ale po dodaniu zmiennej env var do mojego lokalnego środowiska deweloperskiego Mac OS błąd zniknął:

export MY_SERVER_ENV_VAR_NAME ='fake dev security key that is longer than 50 characters.'

W moim przypadku musiałem też dodać --settingsparametr:

python3 manage.py check --deploy --settings myappname.settings.production

gdzie produkcja.py jest plikiem zawierającym ustawienia specyficzne dla produkcji w folderze ustawień.

Samer
źródło
0

Problemem dla mnie było wywołanie get_text_noopiterowalności LANGUAGES.

Wymiana pieniędzy

LANGUAGES = (
    ('en-gb', get_text_noop('British English')),
    ('fr', get_text_noop('French')),
)

do

from django.utils.translation import gettext_lazy as _

LANGUAGES = (
    ('en-gb', _('British English')),
    ('fr', _('French')),
)

w pliku ustawień podstawowych rozwiązał ImproperlyConfigured: The SECRET_KEY setting must not be emptywyjątek.

Sepia
źródło
0

Rozwiązałem powyższy problem, komentując linię w moim settings.py

SECRET_KEY=os.environ.get('SECRET_KEY')

SECRET_KEYzadeklarowane w moim ~/.bashrcpliku (dla użytkowników Linuksa Ubuntu)

Do celów programistycznych na moim komputerze lokalnym nie korzystałem ze zmiennej evironmnet

SECRET_KEY = '(i9b4aes#h1)m3h_8jh^duxrdh$4pu8-q5vkba2yf$ptd1lev_'

powyższa linia nie podała błędu

Ankit Tiwari
źródło
0

W moim przypadku podczas konfigurowania akcji Github po prostu zapomniałem dodać zmienne env do pliku yml:

jobs:
  build:
    env:
     VAR1: 1
     VAR2: 5
Rexcirus
źródło
0

Powodem, dla którego jest tak wiele różnych odpowiedzi, jest to, że wyjątek prawdopodobnie nie ma nic wspólnego z kluczem SECRET_KEY. Prawdopodobnie jest to wcześniejszy wyjątek, który jest połykany. Włącz debugowanie za pomocą DEBUG = True, aby zobaczyć prawdziwy wyjątek.

Amit Klein
źródło
0

W moim przypadku po długich poszukiwaniach stwierdziłem, że PyCharm w ustawieniach Django (Ustawienia> Języki i frameworki> Django) ma niezdefiniowane pole pliku konfiguracyjnego. Powinieneś ustawić to pole na plik ustawień twojego projektu. Następnie należy otworzyć ustawienia uruchamiania / debugowania i usunąć zmienną środowiskową DJANGO_SETTINGS_MODULE = istniejąca ścieżka.

Dzieje się tak, ponieważ wtyczka Django w PyCharm wymusza konfigurację frameworka. Nie ma więc sensu konfigurowanie żadnego os.environ.setdefault ('DJANGO_SETTINGS_MODULE', 'myapp.settings')

Thalles Rosa
źródło
0

Zaimportuj __init__.py sam base.py. upewnij się, że nie powtórzysz tej samej konfiguracji ponownie !.

ustaw zmienną środowiskową SET DJANGO_DEVELOPMENT =dev

settings/
  __init__.py
  base.py
  local.py
  production.py

W __init__.py

from .base import *
if os.environ.get('DJANGO_DEVELOPMENT')=='prod':
   from .production import *
else:
   from .local import *

W base.pyskonfigurowanych konfiguracjach globalnych. z wyjątkiem bazy danych. lubić

SECRET_KEY, ALLOWED_HOSTS,INSTALLED_APPS,MIDDLEWARE .. etc....

W local.py

DATABASES = {
'default': {
    'ENGINE': 'django.db.backends.postgresql_psycopg2',
    'NAME': 'database',
    'USER': 'postgres',
    'PASSWORD': 'password',
    'HOST': 'localhost',
    'PORT': '5432',
}
}
Ramesh Ponnusamy
źródło
0

Przyszedłem tutaj, szukając odpowiedzi, ponieważ miałem te same problemy, żadna z odpowiedzi tutaj nie zadziałała. Następnie po przeszukaniu innych witryn natknąłem się na tę prostą poprawkę. U mnie to zadziałało

wsgi.py

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'yourProject.settings')

do

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'yourProject.settings.dev')
Jayanta Madhav
źródło