runserver error: "No module named app3"

[Bill Beal]

Hi all,

I have a Django project with apps that works OK on a Mac with Django 1.3 and Python 2.6, and I'm trying to move it to a Linux box with Django 1.4 and Python 2.7.  I created an empty project 'proj' with apps 'app1', 'app2', 'app3' on the Linux system and carefully merged settings.py, urls.py etc. with the initial files that were created.  When I run 'python manage.py runserver' it says "Error: no module named app3" if app3 is the last in the list of installed apps (see below), but if I swap app2 and app3 it claims app2 (now the last one in the list) is missing.  The error message seems to be lying to me, and I don't know where to look for the error.  In the settings.py file I have

INSTALLED_APPS = (

    'django.contrib.auth',

    'django.contrib.contenttypes',

    'django.contrib.sessions',

    'django.contrib.sites',

    'django.contrib.messages',

    'django.contrib.staticfiles',

    # Uncomment the next line to enable the admin:

    'django.contrib.admin',

    # Uncomment the next line to enable admin documentation:

    'django.contrib.admindocs',

    'django.django-adminfiles',

    'proj.app1',

    'proj.app2',

    'proj.app3',

)

I've looked around for anything on "Error: No module named xxx", but haven't found any that seem to relate to this behavior.  Has anyone seen this kind of error dependent on the order of the apps?  Is there any way I can force a more informative error?  I tried adding an empty module name at the end, and it gave me an error trace, but I couldn't figure out anything from  it.  My directory tree looks like this:

proj/

    manage.py

proj/proj/

    __init__.py

    settings.py

    urls.py

    wsgi.py

proj/app1/

    __init__.py

    forms.py

    models.py

    tests.py

    views.py

proj/app2/

    __init__.py

    forms.py

    models.py

    tests.py

    views.py

proj/app3/

    __init__.py

    forms.py

    models.py

    tests.py

    views.py

proj/templates/

    . . .

Django 1.4 seems to have a second proj directory under the first level proj directory.  I didn't see this in 1.3.

[Melvyn Sopacua]

Hi Bill,

On 22-8-2012 23:16, Bill Beal wrote:

Look at it like this to spot your error:


> 'proj.app3',

> proj/
^^^^ cwd of the WSGI app

> proj/proj/
> settings.py
^^^^ DJANGO_SETTINGS_MODULE = 'proj.settings'

> proj/app3/

So this module is not proj.app3 but app3.
I'm reasonably sure that the error is only reported on the last entry
because the verification is done in reverse order, but you'll have to
look that up in the source. In either case, "the last of the installed
apps" is a red herring.
--
Melvyn Sopacua

[Bill Beal]

Thanks, Melvin!  That did it.  On to the next error!

[Bill Beal]

Sorry, MELVYN.

[Alexis Bellido]

I'd suggest you decouple your apps from your projects. If you want to have everything under the same tree you could, I don't do it that way though.

You could have a tree like this:

/home/user

--proj

----proj (this contains settings.py in Django 1.4)

----app1

----app2

--app3

You already noticed that Django 1.4 has an inner proj directory which contains settings.py but notice the outer directory doesn't need to be called proj, you could rename it and everything will work. In fact, you could change the inner directory name too if you update the corresponding variables in settings.py (ROOT_URLCONF and WSGI_APPLICATION are the two ones that come to mind).

In my example tree I have app1 and app2 under the outer proj and at the same level with the inner proj and I have app3 at the same level with the outer proj but that doesn't matter much because as long as you have app1, app2 and app3 in your PYTHONPATH you will able to do something like this:

INSTALLED_APPS = (

...

...

    'app1',

    'app2',

    'app3',

)

If you are not using virtualenv and pip yet you should, it helps a lot.

Notice you don't need to include use proj (such as in 'proj.app1') and this is the way to go if you want to reuse your apps in other projects.

Good luck!

[Bill Beal]

I am using pip, and once I tried virtualenv without understanding it and it worked.  There's a kind of knowledge that I call "who's on first" knowledge: you know what comes next but you don't know why.

--
You received this message because you are subscribed to the Google Groups "Django users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/pdq0xqjRk_QJ.

To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.