!!! PONTIFICATION ALERT !!! Don't do that.
I believe that it has always been a goal of project structure that the directories on the python path be either in the default python places (/something/something/lib/python2.X/site-packages/ unless you're using a Debian provided python) or in a directory specific to your Django project. Further, this is a good thing, since it prevents you from being confused by spurious .py files which might be, for example, in your home directory, if your configuration is like Carston's. (What's more, he would be tricked when running under mod_wsgi, but not when using runserver - very confusing.) So putting your home directory on sys.path strikes me as a *BAD THING*(tm). The new way, Django 1.4+, is actually simple to understand. The directory containing manage.py is by default named the same as the directory containing settings.py, urls.py, wsgi.py, etc. (it doesn't have to be: rename it, and fix any wsgi file where you've added it to sys.path, and everything still works). This upper directory is still a place that is specific to the project, so even if it is a sub directory of your home directory, you will be unlikely to put spurious modules in it. Because we cd to it first, when we run a manage.py command, this directory is automatically added to sys.path (you can always import stuff from the current directory as of the starting of python). Since settings.py, urls.py, etc., are in a sub directory named for the project, DJANGO_SETTINGS_MODULE can be set to PROJECTNAME.settings, and in settings.py you can refer to urls.py, wsgi.py, as PROJECTNAME.urls, PROJECTNAME.wsgi, etc. If you have modules or packages to add that you want to qualify, when referenced, with the project name, put them in the lower directory, with settings.py. If you have modules or packages that you don't want to qualify with the the project name, say because you figure that you will eventually put them in site-packages and use them from multiple projects, maybe offering them on pypi, put them in the upper directory with manage.py. The only directory that you need to add to sys.path in your wsgi configuration (not to be confused with PROJECTNAME/wsgi.py) is the directory containing manage.py (you may need to add more if you are using a virtual environment, but that's another story). Note that the upper directory need not be a package (need not contain an __init__.py file). Easy enough to understand, and nicely flexible. In pre-1.4 Django, settings.py and urls.py are in the same directory as manage.py, and a trick is necessary to allow you to set DJANGO_SETTINGS_MODULE to PROJECTNAME.settings and to import urls.py as PROJECTNAME.urls (you could import them as simply settings and urls, but that leads to other issues). To do this, stuff from django used by manage.py (but not in general) temporarily adds the parent directory of the one containing settings.py and urls.py, the only one named for the project, to sys.path, imports PROJECTNAME (the directory must be a package, that is, contain an __init__.py file), and then removes the directory from sys.path again. Later, when trying to import PROJECTNAME.settings or PROJECTNAME.urls, python, since sys.modules already has a package named PROJECTNAME, imports from within it, despite the fact that it is no longer on sys.path. sys.path is only used for looking up the first thing in the dot separated list of names to be imported, and never imports anything twice. When doing a wsgi deployment, later, some folks, like Carston, get it to work by adding the parent directory (permanently) to sys.path. This is fine so long as there are no non-project related modules or packages in that parent directory (and you are sure that there never will be), though there might be some edge cases where this makes deployment behave differently then when using runserver (sys.path is different). The cleanest thing is to make things like when manage.py runs: 1. Insert the directory containing manage.py onto the front of sys.path; 2. insert the parent directory on to sys.path; 3. import PROJECTNAME; and 4. remove the parent directory from sys.path. Bill On Fri, Mar 22, 2013 at 2:40 PM, Carsten Fuchs <[email protected]>wrote: > Hi all, > > I'm currently migrating my Django project that was still in the "old" > project layout to the new default project layout as shown at > <https://docs.djangoproject.**com/en/1.5/intro/reusable-** > apps/#your-project-and-your-**reusable-app<https://docs.djangoproject.com/en/1.5/intro/reusable-apps/#your-project-and-your-reusable-app> > > > > My WSGI file was written as described at > <http://code.google.com/p/**modwsgi/wiki/**IntegrationWithDjango<http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango> > > > > The instructions there say: > >> The directory added to sys.path would be the directory containing the >> package for the Django site created by running: >> >> django-admin.py startproject mysite >> >> In other words, it should be the directory you were in when >> 'django-admin.py' was run. >> > > That is, in the WSGI file I had a line > > sys.path.append('/home/**carsten') > > where my actual project root was '/home/carsten/Zeiterfassung', and > therefore all project-related import statements or targets in the > urlpatterns began with 'Zeiterfassung. ...' > > > However, with the new project layout, it seems that the correct way to > make it work is *contrary* to the description in the IntegrationWithDjango > article: > > Is it right that the python path should now include the project root > directory? > > That is, in my case, I now need > > sys.path.append('/home/**carsten/Zeiterfassung') > > in the WSGI file, because e.g. settings.py is now really at > '/home/carsten/Zeiterfassung/**Zeiterfassung/settings.py'. > > It also means that I have to change all my old import statements ("Lori" > is the app name) from > > from Zeiterfassung.Lori.models import XY > > to > > from Lori.models import XY > > Is that right, and in the sense of the new project layout? > > > I'm asking all this because this being contrary to the > IntegrationWithDjango made me unsure, and <https://docs.djangoproject.** > com/en/1.5/howto/deployment/**wsgi/modwsgi/#basic-**configuration<https://docs.djangoproject.com/en/1.5/howto/deployment/wsgi/modwsgi/#basic-configuration>> > uses both "mysite.com" and "mysite", and says > > The WSGIPythonPath line ensures that your project package is available >> for import on the Python path; in other words, that import mysite works. >> > > but it's still not clear to me if this really expresses the same meaning > as I understood it above. > > Best regards, > Carsten > > > > -- > Dipl.-Inf. Carsten Fuchs > > Carsten Fuchs Software > Industriegebiet 3, c/o Rofu, 55768 Hoppstädten-Weiersbach, Germany > Internet: http://www.cafu.de | E-Mail: [email protected] > > Cafu - the open-source game and graphics engine for multiplayer 3D action > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to > django-users+unsubscribe@**googlegroups.com<django-users%[email protected]> > . > To post to this group, send email to [email protected]. > Visit this group at > http://groups.google.com/**group/django-users?hl=en<http://groups.google.com/group/django-users?hl=en> > . > For more options, visit > https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> > . > > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
