Having an app name the same as project name breaks manage.py ( unable to import projectname.settings )

[simon@…]

When a project has an app with the same name, manage.py breaks.

This might seem like a trivial example - there's probably a good argument to be made why a projectname should be different to an appname, but I think this problem will crop up often on small apps.

Step 1: Create Project fudge & test

minerva:~ simon$ django-admin.py startproject fudge
minerva:~ simon$ cd fudge/
minerva:~/fudge simon$ ls
__init__.py     manage.py       settings.py     urls.py
minerva:~/fudge simon$ python manage.py runserver 80808
Validating models...
0 errors found.

Django version 0.95 (post-magic-removal), using settings 'fudge.settings'
Development server is running at http://127.0.0.1:80808/
Quit the server with CONTROL-C.

Step 2: add an app, also called fudge & try to runserver

minerva:~/fudge simon$ python manage.py startapp fudge
minerva:~/fudge simon$ python manage.py runserver 80808
Traceback (most recent call last):
  File "manage.py", line 11, in ?
    execute_manager(settings)
  File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/django/core/management.py", line 1237, in execute_manager
    execute_from_command_line(action_mapping)
  File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/django/core/management.py", line 1158, in execute_from_command_line
    translation.activate('en-us')
  File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/django/utils/translation.py", line 195, in activate
    _active[currentThread()] = translation(language)
  File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/django/utils/translation.py", line 120, in translation
    if settings.SETTINGS_MODULE is not None:
  File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/django/conf/__init__.py", line 28, in __getattr__
    self._import_settings()
  File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/django/conf/__init__.py", line 55, in _import_settings
    self._target = Settings(settings_module)
  File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/django/conf/__init__.py", line 83, in __init__
    raise EnvironmentError, "Could not import settings '%s' (Is it on sys.path? Does it have syntax errors?): %s" % (self.SETTINGS_MODULE, e)
EnvironmentError: Could not import settings 'fudge.settings' (Is it on sys.path? Does it have syntax errors?): No module named settings

Step 3. Remove fudge app, and try with another app:

minerva:~/fudge simon$ rm -rf fudge/
minerva:~/fudge simon$ python manage.py startapp bork
minerva:~/fudge simon$ python manage.py runserver 80808
Validating models...
0 errors found.

Django version 0.95 (post-magic-removal), using settings 'fudge.settings'
Development server is running at http://127.0.0.1:80808/
Quit the server with CONTROL-C.

[Jacob]

This is a limitation of the way Python's "important" statement works. Read more about it in ​PEP 328, but the short version is that Python 2.5 will fix this problem, but Django's not going to require 2.5 for quite some time now. Hence, I'm marking this WONTFIX -- wish I could!

[Simon Willison]

It would be great if Django could detect this case and provide a more useful error message.

[simon@…]

Note: this is caught with manage.py ( current svn 3338 ):

Error: You cannot create an app with the same name ('fudge') as your project.

[anatoly techtonik]

There is one more case not caught by manage.py and it is very hard to debug. Inside project directory you can't have a package similarly named. Repeatable on Python 2.5/2.7, Django 1.1.2/1.2.3

> python django-admin.py startproject fudge
> cd fudge
> python manage.py runserver
Validating models...
0 errors found

Django version 1.1.2 SVN-14851, using settings 'fudge.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CTRL-BREAK.

Now create child fudge/ directory with __init__.py inside.

>mkdir fudge
>echo #>fudge\__init__.py
>python manage.py runserver --traceback -v 2
Error: Could not import settings 'fudge.settings' (Is it on sys.path? Does it have syntax errors?): No module named settings

I've wasted some precious hours troubleshooting new Rietveld installation due to this bug. Note that traceback is not displayed even though it is requested explicitly.

[Andi Albrecht]

And another case is when you're unhappy and checkout a project into a directory named like a app in this project. IMO should provide better information (at least a hint) why it failed. As mentioned in comment:4 it's a pain to find this error.

[Russell Keith-Magee]

Accepted on the basis that the error message should be more helpful. However, "more helpful" in this case should probably be interpreted as "don't mess around with PYTHONPATH in the first place". This problem only exists because of the way manage.py temporarily alters PYTHONPATH, which is a bit of a glitch (and cause of more than a little confusion).

[Masklinn]

I've run into a false-positive of this issue: it's not possible to create stand-alone applications using the ​standard layout with startapp, short of taking liberties with namings (swapping capitalization around for instance):

> virtualenv --no-site-package foo
New python executable in foo/bin/python
Installing setuptools............done.
> cd foo && . bin/activate
(foo)> easy_install django
Searching for django
[snip]
Finished processing dependencies for django
(foo)> django-admin.py startapp foo
Error: You cannot create an app with the same name ('foo') as your project.

Here, there is no project at all, yet startapp whines.

[Yaşar Arabacı]

Fixes comment 12

[darkowlzz]

The bug has been fixed in trunk, apps with same name as project name can be created now

[anatoly techtonik]

Great. Is there any way to know which branch/commit fixed that?

Are Trac hooks enabled for this installation?
​http://trac.edgewall.org/wiki/TracFaq#can-trac-automatically-update-a-ticket-when-i-commit-a-changeset

[Ramiro Morales]

Replying to techtonik:

Great. Is there any way to know which branch/commit fixed that?

The branch is tehd evelopment trunk.

Are Trac hooks enabled for this installation?
​http://trac.edgewall.org/wiki/TracFaq#can-trac-automatically-update-a-ticket-when-i-commit-a-changeset

Yes we use that Trac feature. Problem is that the issue reported in this tikcet has been fixed by working on another ticket or in a refactoring of the code. And tickets hadn't been triaged to discover they were duplicate and unify them or simply this one passed unnoticed.

So, if you need to knwo the exact SVN revision where this was fixed feel free to apply some kind of bisection method to discover it.

[Luke Plant]

If it is fixed on trunk, it should be just closed as fixed, not changed to 'fixed on a branch'.

This was most likely fixed in [16964]