Code

Opened 8 years ago

Closed 3 years ago

Last modified 3 years ago

#1908 closed Bug (fixed)

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

Reported by: simon@… Owned by: adrian
Component: Core (Management commands) Version: master
Severity: Normal Keywords:
Cc: albrecht.andi@…, techtonik@…, lrekucki@…, yasar11732, 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)

directory_name_fix.diff (1.4 KB) - added by yasar11732 3 years ago.
Fixes comment 12

Download all attachments as: .zip

Change History (19)

comment:1 Changed 8 years ago by jacob

  • Resolution set to wontfix
  • Status changed from new to closed

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!

comment:2 Changed 8 years ago by Simon Willison

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

comment:3 Changed 8 years ago by simon@…

  • Version set to 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 Changed 4 years ago by techtonik

  • Resolution wontfix deleted
  • Status changed from closed to 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 Changed 4 years ago by andialbrecht

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 Changed 4 years ago by andialbrecht

  • Cc albrecht.andi@… added

comment:7 Changed 4 years ago by techtonik

  • Cc techtonik added

comment:8 Changed 4 years ago by techtonik

  • Cc techtonik@… added; techtonik removed

comment:9 Changed 4 years ago by russellm

  • Triage Stage changed from Unreviewed to 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 Changed 3 years ago by lrekucki

  • Cc lrekucki@… added

comment:11 Changed 3 years ago by lrekucki

  • Severity changed from normal to Normal
  • Type changed from defect to Bug

comment:12 Changed 3 years ago by 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.

Changed 3 years ago by yasar11732

Fixes comment 12

comment:13 Changed 3 years ago by yasar11732

  • Cc yasar11732 added
  • Easy pickings unset
  • UI/UX unset

comment:14 Changed 3 years ago by yasar11732

  • Easy pickings set
  • UI/UX set

comment:15 Changed 3 years ago by darkowlzz

  • Cc darkowlzz added
  • Resolution set to fixed
  • Status changed from reopened to closed
  • Triage Stage changed from Accepted to Fixed on a branch

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

Last edited 3 years ago by darkowlzz (previous) (diff)

comment:16 follow-up: Changed 3 years ago by 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

comment:17 in reply to: ↑ 16 Changed 3 years ago by ramiro

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.

Last edited 3 years ago by ramiro (previous) (diff)

comment:18 Changed 3 years ago by lukeplant

  • Triage Stage changed from Fixed on a branch to 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]

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.