Graham Dumpleton wrote:
> On Jul 6, 2:59 pm, John-Scott <[EMAIL PROTECTED]> wrote:
>> On Jul 6, 12:29 am, Graham Dumpleton <[EMAIL PROTECTED]>
>> wrote:
>>
>>> Hmmm, I'm not sure the documentation is actually accurate. When you
>>> use manage.py to run up development server for Django, it will
>>> automatically add the parent directory of where the manage.py file is
>>> located into sys.path for you. Thus, there isn't strictly a need to
>>> add it to PYTHONPATH to get it to work in the first place.
>>> So, the answer is that YES, for mod_python you must use the PythonPath
>>> directive to specify the parent directory of where manage.py is
>>> located in order for your settings file to be found correctly.
>>> Graham
>> Graham - I was suspicious of that. I remember reading that manage.py
>> took care of setting all the environment variables for the development
>> server and interactive shell. But it didn't seem possible for
>> mod_python to have any idea where our projects are implicitly. Should
>> we file a doc bug?
>
> Someone can correct me, but I think it gets a bit more confusing than
> that, so there is possibly other changes which should be made to the
> mod_python documentation.
>
> When using manage.py it imports settings.py explicitly, thus there is
> no need to define DJANGO_SETTINGS_MODULE like with mod_python to say
> what the actual settings module name is. At this point though, only
> the directory containing manage.py is effectively in sys.path. This
> would mean that where you have in urls.py:
>
> (r'^mysite1/', include('mysite1.apps.foo.urls.foo')),
>
> it would actually fail to find the referenced module.
>
> In searching through Django, the only place it adds the parent
> directory to sys.path so that it might find that referenced module is:
>
> def setup_environ(settings_mod):
> """
> Configure the runtime environment. This can also be used by
> external
> scripts wanting to set up a similar environment to manage.py.
> """
> # Add this project to sys.path so that it's importable in the
> conventional
> # way. For example, if this file (manage.py) lives in a directory
> # "myproject", this code would add "/path/to/myproject" to
> sys.path.
> project_directory = os.path.dirname(settings_mod.__file__)
> project_name = os.path.basename(project_directory)
> sys.path.append(os.path.join(project_directory, '..'))
> project_module = __import__(project_name, {}, {}, [''])
> sys.path.pop()
>
> If you look carefully, what it does is append the parent directory to
> sys.path and imports the name of the site directory itself. This has
> the effect of importing the __init__.py in the site directory. It then
> removes the parent directory from sys.path.
>
> Even though it has removed the parent directory from sys.path, the
> import of the module referenced in urls.py by the site name still
> works because of the presence of the 'mysite1' module in sys.modules.
> Ie., Python sees that module, works out from __file__ of the module
> where it is located and searches for the submodule relative to that
> directory.
>
> So, importing modules by site package root is okay, but problem is
> that the site directory itself is still in sys.path. This means one
> can actually do:
>
> (r'^mysite1/', include('apps.foo.urls.foo')),
>
> Ie., one can leave out the site name in the module path and it will
> still work.
>
> Some people do imports this way as it means that if you rename the
> site you don't have to change the urls.py file. Also, easier to
> develop reusable components that you can copy from one project to
> another.
>
> The problem with this is that if an application which uses these
> imports without the site name in them is hosted on mod_python, it will
> not work. This is because not only do you have to set PythonPath to
> include the parent directory of the site, you also have to list the
> site directory path itself. Ie.,
>
> PythonPath "['/path/to/parent','/path/to/parent/mysite1'] +
> sys.path"
"will not work" is alarming, but then you say "also have to..." which makes me
think it will work. so only problem is PythonPath having an extra entry, right?
I have been developing my site under the impression that whatever works with
./manage.py runserver will work with mod_python without having to touch 'the
app' (I expect to have to touch httpd.conf files.)
Personally, I am not trilled by some of the search path behavior, but the root
of that is native python, and so as long as django's behavior is somewhat
consistent with Python's, I will live with it. If there is something that
strays too far and is causing problems, I may get fanatical about it.
I setup
>
> I am not sure this is clearly mentioned in the mod_python document for
> Django or not.
>
> Certainly, the need to do this is explained on the mailing list every
> so often, so there must be some confusion about it.
I setup a mod_python server last week, and it did seem like the docs were not
as
straight forward as they should be. my feeling was "you probably should do X
and Y and maybe Z" when it should be worded "you probably should do X, Y and Z"
and some explanation why Z could be optional. I will be doing it again next
week and will post something a bit more definitive.
Carl K
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
