ImportError in Django App only when I start server from IDE
I am trying to get an existing Django project to run under the PyCharm IDE on an Ubuntu system. The curious thing is, I can run the server, e.g. by running
manage.py runserver localhost:8000
in the terminal, but even though I have configured the Django settings in PyCharm, I get an ImportError when I use the IDE's Run or Debug buttons.
This is what I have configured:
- enabled Django support in the settings and set the Django Project Root to my home: set project root to a subdirectory of my project (same name as the project) which contains settings and scripts; set the settings file; set the manage script
- added a Django configuration as follows, including a Python virtual environment

When I run this configuration, I get the following output (replaced project name, added ellipsis marks):
/home/franz/work/virtualEnvironments/<projectname>/bin/python3 /home/franz/work/repositories/<projectname>/<projectname>/scripts/manage.py runserver 8000
Traceback (most recent call last):
File "/home/franz/work/repositories/<projectname>/<projectname>/scripts/manage.py", line 18, in <module>
main()
... ... ...
File "<frozen importlib._bootstrap>", line 969, in _find_and_load
File "<frozen importlib._bootstrap>", line 956, in _find_and_load_unlocked
ImportError: No module named 'settings'
Process finished with exit code 1
The curious thing is, when I run the exact same command from the first output line separately in a Terminal, like this:
/home/franz/work/virtualEnvironments/<projectname>/bin/python3 /home/franz/work/repositories/<projectname>/<projectname>/scripts/manage.py runserver 8000
the server runs perfectly fine. Also running the runserver command in the Django Console
manage.py@sennder > runserver
runs the server. But I would like to run (and debug) it directly from the IDE.
This is what I also know
- under Mac OS, I could run the server by clicking 'Run' in the IDE without problems
- a colleage can run the server from PyCharm without problems from Ubuntu as well
- as already stated, I can run the server from the Terminal and also from the Django Console (Ctrl+Alt+R)
- When I create a Django project from scratch within PyCharm, it runs without problems in the same virtual environment
I would appreciate every help, as I have already spent a lot of hours trying to figure out how to run the server from PyCharm directly.
Thank you.
请先登录再写评论。
Hi Franz! Could you please try to remove environment variable SETTINGS_MODULE from your run configuration? Has it helped?
Hi Pavel! Thanks. Your hint led me to the right direction. Now I found a solution.
The text SETTINGS_MODULE from the dialog screenshot was a cut version of DJANGO_SETTINGS_MODULE. I removed the environment variable from the run configuration, tried to run the server and got the same error again.
Apparently PyCharm has added an environment variable DJANGO_SETTINGS_MODULE again with the (wrong) value settings.development, overriding the (correct) default from manage.py:
(Seemingly the IDE didn't set the environment variable under my previous Mac OS IDE configuration, which I cannot check anymore now. In a new Django project, the directory structure is different, so that the automatically added env. variable has the correct value.)
To resolve the issue, I manually changed the environment variable DJANGO_SETTINGS_MODULE to the correct value <projectname>.settings.development. Now I can start the server from the IDE with Run/Debug.
Maybe the automatic setting of the wrong env. variable is an issue in PyCharm?
Hm, could you please check Settings | Languages & Frameworks | Django | Settings option? Has it a correct path to your settings file?
Yes, I double checked and everything is correct.
Yes this problem is not yet saved in 2020 version. You need to manully configure the ENVIRONMENT VARIABLES under the Run/ DEBUG configuration window like this "PYTHONUNBUFFERED=1;DJANGO_SETTINGS_MODULE=<project_name>.settings" with your project name
This issue was driving me nuts, thanks for the solution - kind of disappointing, that this basic feature is broken for at least 3 years, without any documentation.