0

I'm trying to configure Django with

python manage.py shell

And I get the error:

Traceback (most recent call last):
  File "manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/usr/lib64/python2.7/site-packages/django/core/management/__init__.py", line 367, in execute_from_command_line
    utility.execute()
  File "/usr/lib64/python2.7/site-packages/django/core/management/__init__.py", line 341, in execute
    django.setup()
  File "/usr/lib64/python2.7/site-packages/django/__init__.py", line 27, in setup
    apps.populate(settings.INSTALLED_APPS)
  File "/usr/lib64/python2.7/site-packages/django/apps/registry.py", line 85, in populate
    app_config = AppConfig.create(entry)
  File "/usr/lib64/python2.7/site-packages/django/apps/config.py", line 123, in create
    import_module(entry)
  File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
ImportError: No module named django

I've seen a lot of questions about this error, and most of them seem to be centered on the fact that django's path is not included in python's sys.path. Mine is, however. When I run 

sudo pip install django

I get

Requirement already satisfied: django in /usr/lib64/python2.7/site-packages

And the output for my sys.path is

['', '/usr/lib64/python27.zip', '/usr/lib64/python2.7', '/usr/lib64/python2.7/plat-linux2', '/usr/lib64/python2.7/lib-tk', '/usr/lib64/python2.7/lib-old', '/usr/lib64/python2.7/lib-dynload', '/usr/lib64/python2.7/site-packages', '/usr/lib64/python2.7/site-packages/gtk-2.0', '/usr/lib/python2.7/site-packages']

So the path is absolutely there. What are my options here? This is a remote interpreter using SSH from Pycharm, and it's seriously delaying my work.

Nathan Whitney
  • 1
  • 2
  • Did you use a virtual env when installing django? – Evans Murithi Nov 22 '16 at 21:14
  • I didn't, I'm relatively unfamiliar with virtual env. Is there any reason to use one when there only exists one python version on the virtual machine? – Nathan Whitney Nov 22 '16 at 21:17
  • https://virtualenvwrapper.readthedocs.io/en/latest/ – copser Nov 22 '16 at 21:18
  • You might have lets say two different projects each using a different django version from the other – Evans Murithi Nov 22 '16 at 21:18
  • Installed everything in virtual env, the error is still there. Only difference is the installation path now points to the virtual env, but my new django path is in the sys.path and the error remains. – Nathan Whitney Nov 22 '16 at 21:33
  • What is your operating system (and version)? How did you install Python? Is the Python run by the superuser the same as the Python run by the normal user? Try `which python`. Then try `sudo -s` and again `which python` (and then `exit` to get out of sudo). What are the results? – Antonis Christofides Nov 23 '16 at 07:42
  • Considering virtualenvs, they are always a good idea, but it's no big deal to do it like you're doing it now while you are a beginner. You may find my article, "virtualenv demystified", useful: http://djangodeployment.com/2016/11/01/virtualenv-demystified/ – Antonis Christofides Nov 23 '16 at 07:47
  • Normal user python returns ~/bin/python Sudo returns /bin/python I can check about the OS in a little bit and get back to you – Nathan Whitney Nov 23 '16 at 15:24
  • Activate the virtual env and run the command `django-admin shell` in bash. `django-admin` does the same as `python manage.py`, but it's on `$PATH`, so you can use it from any directory when you have activated the virtual env. – Håken Lid Nov 23 '16 at 17:53
  • This gives me: django.core.exceptions.ImproperlyConfigured: Requested setting DATABASES, but settings are not configured. Which is the reason i'm trying to run manage.py in the first place. I already tried running settings.configure() in the python shell but it seems to do nothing... – Nathan Whitney Nov 23 '16 at 18:07
  • When using `django-admin` you need to give it the location of your settings module. Typically by setting the env variable `DJANGO_SETTINGS_MODULE`. Read the relevant docs here for more info. https://docs.djangoproject.com/en/1.10/ref/django-admin/ – Håken Lid Nov 23 '16 at 18:22

1 Answers1

1

If which python, when run by the normal user, returns ~/bin/python, then this is a different Python from the one run by the superuser, which, according to what you say, is /bin/python. sudo pip install django runs as the superuser and installs Django in the system's Python environment. When, afterwards, you execute python manage.py shell, it runs another Python, and that other Python's environment apparently doesn't have Django installed.

If you run pip install django without the sudo it might work, but since you have superuser permission on that machine it would be better to get rid of the Python installation that you have in the normal user's home directory, and make sure your system has only one Python installation until you really know what you are doing. Otherwise you will be confused whether you use virtualenv or not.

Edit: I disagree with many comments that tell you to use virtualenv. You are confused enough without it. Let's simplify the problem first. Remove all virtualenvs you have created (you do this by deleting the directories) and forget everything about virtualenv. Logout and login again (this will ensure the virtualenvs are deactivated). Don't modify your manage.py, it's fine as it was originally. Install Django system-wide with sudo pip install django, then try to run your Django project with python manage.py shell. Only after you get it working and you start having a grip on the system go on to start playing with virtualenv. Virtualenv is great, but everything in its time. (virtualenv demystified is an introduction to virtualenv written by me.)

Antonis Christofides
  • 5,658
  • 31
  • 45
  • However, I installed django in my virtual environment with pip install django, not using sudo at all. So I think django is installed in both the system and the virtual paths... Would removing the user's home python help me at this point? – Nathan Whitney Nov 23 '16 at 17:15
  • Looks like you have django installed globally, not in a virtual environment `/usr/lib64/python2.7/site-packages/django/`. – Håken Lid Nov 23 '16 at 17:30
  • I just deleted and re-instantiated the virtualenv. Curiously, I can type import django in python terminal and it works fine. my manage.py has #!/usr/bin/env python at the top. I will try modifying this, any other ideas? – Nathan Whitney Nov 23 '16 at 17:41
  • the django command tells me django is installed at /var/www/lib/python2.7/site-packages/django/__init__.pyc', if this matters – Nathan Whitney Nov 23 '16 at 17:43
  • Looks like a probable mix up between the django in the virtual env (/var/www/lib) and the globally installed django (/usr/lib64/). Why do you need to have a version of django installed globally, anyway? – Håken Lid Nov 23 '16 at 17:51
  • Not sure. How should I remove the global version? But that /usr/lib64 was from before I used a virtualenv, this it my new sys.path: ['', '/var/www/lib64/python27.zip', '/var/www/lib64/python2.7', '/var/www/lib64/python2.7/plat-linux2', '/var/www/lib64/python2.7/lib-tk', '/var/www/lib64/python2.7/lib-old', '/var/www/lib64/python2.7/lib-dynload', '/usr/lib64/python2.7', '/usr/lib/python2.7', '/var/www/lib/python2.7/site-packages'] – Nathan Whitney Nov 23 '16 at 17:57
  • In ubuntu or debian, to remove global version `sudo pip uninstall django`. It should just remove the django library installed in `/usr/lib64/python2.7` – Håken Lid Nov 23 '16 at 18:08
  • Did that, error remains. Confirmed django exists, when running pip install django, it says it exists in /var/www/lib/python2.7/site-packages Should I edit the manage.py? The last part of the error message says: File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module __import__(name) ImportError: No module named django And I notice the /usr/lib64 path is still mentioned in this error... – Nathan Whitney Nov 23 '16 at 18:13
  • There should be no need to edit manage.py. The first line is only an instruction to bash. I can't see how it would change anything in your situation, but if you are curious, its function is explained here: http://stackoverflow.com/questions/2429511/why-do-people-write-usr-bin-env-python-on-the-first-line-of-a-python-script – Håken Lid Nov 23 '16 at 18:25