project_directory calculated incorrectly when "settings" is a directory (breaks 'startapp')

[Chris Lamb]

When a Django project's settings is contained in directory-style module instead of the usual "settings.py" file-based module, project_directory (as returned from setup_environ) is calculated incorrectly as "settings", which results in--at least--'startapp' creating new apps inside the settings directory.

Whilst the use of a settings directory is non-standard, it helps when splitting larger or more complicated configurations, such as when settings change depending on the hostname, etc. Indeed, this would be completely transparent to Django if it wasn't parsing the __file__ attribute.

To reproduce:

 % django-admin.py startproject myproject
 % cd myproject
 % mkdir settings
 % mv settings.py settings/__init__.py
 % ./manage.py startapp myapp
 % tree
 |-- __init__.py
 |-- manage.py
 |-- settings
 |   |-- __init__.py
 |   `-- myapp                              # <----
 |       |-- __init__.py
 |       |-- models.py
 |       `-- views.py
 `-- urls.py

Patch attached.

[Chris Lamb]

Rebasing patch against HEAD

[Chris Lamb]

0001-Fix-project_name-location-when-settings-is-a-module.patch

[Chris Lamb]

Rebasing patch against HEAD.

[Alex Robbins]

06-fix-project_name-location-when-settings-is-a-module.patch does fix the bug. It also breaks 37 of the admin_scripts regression tests. Somehow it causes the spawned admin commands to die with a "TypeError: relative imports require the 'package' argument" traceback.

[Alex Robbins]

Looks like the conditional the patch added (if settings_name == "init") is being excecuted during the tests, even though I don't think they are using a settings directory. Not exactly sure why that is.

[George Song]

My patch fixes a few problems:

1. get_commands() was importing project settings each time it's called. That's not necessary.
2. get_commands() was actually passing the project package instead of settings module/package to setup_environ().
3. In setup_environ(), check to see if settings module is a package or module by checking to see if its file contains init.py or not. Not sure if this works for Jython as I don't know how Jython filenames work.

[Eric Holscher]

Trying to write tests for this.

[Eric Holscher]

Basic patch, removed the sys.modules import, and it seems to work without all that split() stuff, but if there's a reason that was there, feel free to add it back.

[Eric Holscher]

All tests pass, and the regression test (first at the top of that patch) fails on current trunk and passes with the patch.

[George Song]

The reason for using sys.modules lookup instead of import_module() was to prevent the setting module from unnecessarily being imported again, since it would have to have been imported by this point.

[Alex Gaynor]

import doesn't redo an imoprt if it's already in sys.modules.

[Jacob]

(In [10751]) Fixed #9751: admin scripts now calculate the project directory correctly when the settings module is a directory with an init.py. Thanks to Eric Holscher.

[Leo Shklovskii]

This fix broke our configuration - documented in #11147.

[Jacob]

Milestone 1.1 deleted