Re: Python path in new 1.4 project structure?

[Shawn Milochik]

On Mon, Mar 25, 2013 at 12:56 PM, Carsten Fuchs  wrote:
>> !!! PONTIFICATION ALERT !!!
>> Don't do that.
>
> Uhh, about the first word, I didn't find it in any dictionary.
> Is this somehow related to pope Franziskus?  ;-)
>

>From http://www.thefreedictionary.com/pontificate:
To express opinions or judgments in a dogmatic way.

He meant it as a humorous disclaimer.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Python path in new 1.4 project structure?

[Carsten Fuchs]

Hi Bill,

thank you very much for your clear and detailed reply!
All problems resolved.

Am 22.03.2013 20:52, schrieb Bill Freeman:

!!! PONTIFICATION ALERT !!!
Don't do that.


Uhh, about the first word, I didn't find it in any dictionary.
Is this somehow related to pope Franziskus?  ;-)


So putting your home directory on
sys.path strikes me as a *BAD THING*(tm).


Well, yes, but when for the first time I worked through the tutorials 
(with pre-1.4 Django), the perfect place to call   django-admin.py 
startproject mysite   at this time seemed to be the home directory.  ;)



Again, many thanks for your help: I managed to get everything updated to 
all the best practices mentioned both in the Django tutorials and in the 
"Two Scoops of Django" book (all of which are excellently written).


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: i...@cafu.de

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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Python path in new 1.4 project structure?

[Bill Freeman]

!!! 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 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
>  apps/#your-project-and-your-**reusable-app
> >
>
> My WSGI file was written as described at
> 
> >
>
> 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 

Python path in new 1.4 project structure?

[Carsten Fuchs]

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



My WSGI file was written as described at


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 
 
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: i...@cafu.de

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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.