I know what you are saying about code protection, but in the case of a site hosted on some hosting server you don't have much options. I admit I'm not aware of mod_python internals, I've just use it this as an example to illustrate my idea for an easier deployment. It doesn't have to be in the form I've presented it, but maybe with some ideas from other more experienced users we can get somewhere, maybe triggering this behavior with an condition using an environment variable, I don't know, I'm learning python :). I think advanced deployment of an application are being done by experienced users, newbies will read the tutorials and the path to sys.path as it specified there, so the idea was that django to do that automatically for them which is in concordance with django philosophy.
On May 9, 2:12 am, Graham Dumpleton <[EMAIL PROTECTED]> wrote: > On May 9, 9:06 am, Graham Dumpleton <[EMAIL PROTECTED]> > wrote: > > > > > On May 8, 10:07 pm, Andrei <[EMAIL PROTECTED]> wrote: > > > > I think it would be useful to add the path to the project > > > automatically to sys.path. I can't think of a situation in which I > > > wouldn't need to change the pythonpath and my project still would > > > work. You need to have the applications in the path in order for the > > > import to work and why shouldn't that be done by django ? > > > > An example patch for modpython is: > > > > Index: django/core/handlers/modpython.py > > > =================================================================== > > > --- django/core/handlers/modpython.py (revision 7519) > > > +++ django/core/handlers/modpython.py (working copy) > > > @@ -143,6 +143,8 @@ > > > def __call__(self, req): > > > #mod_pythonfakes the environ, and thus doesn't process > > > SetEnv. This fixes that > > > os.environ.update(req.subprocess_env) > > > + import sys > > > + sys.path.append(req.hlist.directory) > > > > # now that the environ works we can see the correct settings, > > > so imports > > > # that use settings now can work > > > > Then you could have an .htaccess in project directory like this: > > > > SetHandler python-program > > > PythonHandler django.core.handlers.modpython > > > SetEnv DJANGO_SETTINGS_MODULE settings > > > PythonDebug On > > > > which enablesmod_pythonfor the project no matter where it is placed > > > and no matter which is the name of the project. > > > > Also you can reference the applications without using <project_name>. > > > in front of the reference wich is usefull if you want to reuse the > > > project with a different name. > > > The value req.hlist.directory is only present in mod_python 3.3.1 and > > is mostly an internal implementation detail and not strictly a part of > > the public API. > > Sorry, mean to say only in mod_python 3.X. Ie., not in 2.7 which I > believe mod_python can also work on these days. > > > The value of req.hlist.directory should never be added to sys.path as > > then you create an overlap between directories managed in sys.path and > > those managed by mod_python module importer. This can result in > > modules being imported multiple times under different names as > > mod_python modules are not imported under the name of the module, but > > an encoded name of the absolute path of the module. > > Also, these comment are also relevant to mod_python 3.3.1. In older > versions things were done different, which raises another problem in > that things may behave differently for different versions of > mod_python. > > > That this would even make a difference for you suggests you are also > > breaking a very important rule related to using mod_python. That is, > > that you should not put incidental code outside of the mod_python > > handler being used, in the directory which is being served by Apache. > > The reason you shouldn't do this is because a misconfiguration of > > Apache will expose all your source code for download, including any > > sensitive database passwords and magic values you may have stored in > > them. > > > I'd suggest you review what you are doing, as it isn't a very safe > > practice. > > Either way, still recommend against this change. > > Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~----------~----~----~----~------~----~------~--~---
