#1908 closed Bug (fixed)
Having an app name the same as project name breaks manage.py ( unable to import projectname.settings )
Reported by: | Owned by: | Adrian Holovaty | |
---|---|---|---|
Component: | Core (Management commands) | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | albrecht.andi@…, techtonik@…, lrekucki@…, Yaşar Arabacı, darkowlzz | Triage Stage: | Accepted |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | yes | UI/UX: | yes |
Description
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.
Attachments (1)
Change History (19)
comment:1 by , 18 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:2 by , 18 years ago
It would be great if Django could detect this case and provide a more useful error message.
comment:3 by , 18 years ago
Version: | → SVN |
---|
Note: this is caught with manage.py ( current svn 3338 ):
Error: You cannot create an app with the same name ('fudge') as your project.
comment:4 by , 14 years ago
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
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.
comment:5 by , 14 years ago
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.
comment:6 by , 14 years ago
Cc: | added |
---|
comment:7 by , 14 years ago
Cc: | added |
---|
comment:8 by , 14 years ago
Cc: | added; removed |
---|
comment:9 by , 14 years ago
Triage Stage: | Unreviewed → Accepted |
---|
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).
comment:10 by , 14 years ago
Cc: | added |
---|
comment:11 by , 14 years ago
Severity: | normal → Normal |
---|---|
Type: | defect → Bug |
comment:12 by , 14 years ago
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.
comment:13 by , 13 years ago
Cc: | added |
---|---|
Easy pickings: | unset |
UI/UX: | unset |
comment:14 by , 13 years ago
Easy pickings: | set |
---|---|
UI/UX: | set |
comment:15 by , 13 years ago
Cc: | added |
---|---|
Resolution: | → fixed |
Status: | reopened → closed |
Triage Stage: | Accepted → Fixed on a branch |
The bug has been fixed in trunk, apps with same name as project name can be created now
follow-up: 17 comment:16 by , 13 years ago
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
comment:17 by , 13 years ago
Replying to techtonik:
Great. Is there any way to know which branch/commit fixed that?
The branch is tehd evelopment trunk.
As for the
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.
comment:18 by , 13 years ago
Triage Stage: | Fixed on a branch → Accepted |
---|
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]
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!