Open tcardenasc opened 1 month ago
maximiliancw
commented
1 month ago +1
Even with
# General
APPEND_SLASH = False
TIME_ZONE = 'UTC'
LANGUAGE_CODE = 'en-us'
# If you set this to False, Django will make some optimizations so as not
# to load the internationalization machinery.
USE_I18N = False
USE_L10N = False
USE_TZ = True
LOGIN_REDIRECT_URL = '/'in settings.py, it won't run in my case.
tcardenasc
commented
1 month ago We found a simple fix! Just change the docker python version from 3.12-slim to 3.12.4-slim in the Dockerfile
FROM python:3.12.4-slim as base
maximiliancw
commented
1 month ago Confirmed. Thanks!
danielju91
commented
1 week ago I MIGHT have found the cause of this issue. I wasn't really able to thoroughly test this but here is what I found.
When I first experienced the error, I fixed it by changing the Dockerfile as mentioned.
However, later after I have progressed with adding some apps and other objects, when I tried to run in venv:
python manage.py makemigrations
I was getting a similar error (not sure if exactly the same. Computer name and part of path obfuscated)
(venv) user@COMPUTER:~$ python manage.py makemigrations
Traceback (most recent call last):
File "/.../manage.py", line 30, in <module>
main()
File "/.../manage.py", line 26, in main
execute_from_command_line(sys.argv)
File "/.../venv/lib/python3.12/site-packages/django/core/management/__init__.py", line 442, in execute_from_command_line
utility.execute()
File "/.../venv/lib/python3.12/site-packages/django/core/management/__init__.py", line 436, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/.../venv/lib/python3.12/site-packages/django/core/management/base.py", line 413, in run_from_argv
self.execute(*args, **cmd_options)
File "/.../venv/lib/python3.12/site-packages/django/core/management/base.py", line 454, in execute
self.check()
File "/.../venv/lib/python3.12/site-packages/django/core/management/base.py", line 486, in check
all_issues = checks.run_checks(
^^^^^^^^^^^^^^^^^^
File "/.../venv/lib/python3.12/site-packages/django/core/checks/registry.py", line 88, in run_checks
new_errors = check(app_configs=app_configs, databases=databases)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/.../venv/lib/python3.12/site-packages/django/core/checks/translation.py", line 62, in check_language_settings_consistent
get_supported_language_variant(settings.LANGUAGE_CODE)
File "/.../venv/lib/python3.12/site-packages/django/utils/translation/__init__.py", line 256, in get_supported_language_variant
return _trans.get_supported_language_variant(lang_code, strict)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/.../venv/lib/python3.12/site-packages/django/utils/translation/trans_real.py", line 535, in get_supported_language_variant
if code.lower() in supported_lang_codes and check_for_language(code):
^^^^^^^^^^^^^^^^^^^^^^^^
File "/.../venv/lib/python3.12/site-packages/django/utils/translation/trans_real.py", line 480, in check_for_language
for path in all_locale_paths()
^^^^^^^^^^^^^^^^^^
File "/.../venv/lib/python3.12/site-packages/django/utils/translation/trans_real.py", line 457, in all_locale_paths
for app_config in apps.get_app_configs():
^^^^^^^^^^^^^^^^^^^^^^
File "/.../venv/lib/python3.12/site-packages/django/apps/registry.py", line 147, in get_app_configs
self.check_apps_ready()
File "/.../venv/lib/python3.12/site-packages/django/apps/registry.py", line 138, in check_apps_ready
raise AppRegistryNotReady("Apps aren't loaded yet.")
django.core.exceptions.AppRegistryNotReady: Apps aren't loaded yet.I looked everywhere for a solution. But then I realized trying to run Django locally without Docker (using python manage.py runserver, would return CommandError: You must set settings.ALLOWED_HOSTS if DEBUG is False., suggesting that the settings from common.py and local.py were not being imported correctly. So, to troubleshoot, I modified the manage.py in my primary app folder (in my case backend_main) like below:
#!/usr/bin/env python
"""Django's command-line utility for administrative tasks."""
import os
import sys
def main():
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "backend_main.config")
os.environ.setdefault("DJANGO_CONFIGURATION", "Local")
try:
from configurations.management import execute_from_command_line
from django.conf import settings # Import settings here
except ImportError:
# The above import may fail for some other reason. Ensure that the
# issue is really that Django is missing to avoid masking other
# exceptions on Python 2.
try:
import django # noqa
except ImportError:
raise ImportError(
"Couldn't import Django. Are you sure it's installed and "
"available on your PYTHONPATH environment variable? Did you "
"forget to activate a virtual environment?"
)
raise
# Print settings
for setting in dir(settings):
if setting.isupper():
print(f"{setting}: {getattr(settings, setting)}")
execute_from_command_line(sys.argv)
if __name__ == '__main__':
main()When I did that, quite accidentally because I was trying to import django.conf.settings, it revealed that the problem was that there was a problem with importing settings from django.conf because of a missing package. Below was printed in the terminal:
Traceback (most recent call last):
File "/.../manage.py", line 39, in <module>
main()
File "/.../manage.py", line 30, in main
for setting in dir(settings):
^^^^^^^^^^^^^
File "/.../venv/lib/python3.12/site-packages/django/utils/functional.py", line 251, in inner
self._setup()
File "/.../venv/lib/python3.12/site-packages/django/conf/__init__.py", line 68, in _setup
self._wrapped = Settings(settings_module)
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/.../venv/lib/python3.12/site-packages/django/conf/__init__.py", line 166, in __init__
mod = importlib.import_module(self.SETTINGS_MODULE)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/importlib/__init__.py", line 90, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "<frozen importlib._bootstrap>", line 1387, in _gcd_import
File "<frozen importlib._bootstrap>", line 1360, in _find_and_load
File "<frozen importlib._bootstrap>", line 1331, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 919, in _load_unlocked
File "<frozen importlib._bootstrap>", line 879, in _load_backward_compatible
File "/.../venv/lib/python3.12/site-packages/configurations/importer.py", line 152, in load_module
self.spec.loader.exec_module(mod)
File "<frozen importlib._bootstrap_external>", line 995, in exec_module
File "<frozen importlib._bootstrap>", line 488, in _call_with_frames_removed
File "/.../backend_main/config/__init__.py", line 1, in <module>
from .local import Local # noqa
^^^^^^^^^^^^^^^^^^^^^^^^
File "/.../backend_main/config/local.py", line 2, in <module>
from .common import Common
File "/.../backend_main/config/common.py", line 3, in <module>
from distutils.util import strtobool
ModuleNotFoundError: No module named 'distutils'So, it turns distutils was removed in Python3.12, replaced by setuptools, which is not included in the requirements.txt of this cookiecutter project yet. This might be the reason why newly scaffolded projects are experiencing this problem.
When I installed setuptools (pip install setuptools) in the venv, the issue went away and I was able to python manage.py makemigrations and python manage.py runserver without problem.
I have not yet verified if running the Dockerfile with FROM python:3.12-slim as base with setuptools included in the requirements.txt resolves the original "AppRegistry Not Ready" issue. My guess is this might have been the cause from the beginning, where deprecated packages (distutils or some other package) that are causing issues during imports just showing up as "AppRegistry Not Ready." The error handling for this message does not seem very particular under the hood. If nothing else, maybe a method like this could be useful for pinpointing the issue.
I hope this will be helpful in sorting this issue out.
What's going wrong?
How can the
cookiecutter-django-restteam reproduce the problem?OS: Fedora Workstation 40, kernel 6.10.11-200.fc40
cookiecutter gh:agconti/cookiecutter-django-restdocker-compose upThis traceback is exactly the same as the GitHub Actions tests, starting on https://github.com/agconti/cookiecutter-django-rest/actions/runs/10701302403/job/29666963247
Is this a problem with a fresh install of the project?