Ha.. You're describing the same problems that we had with a growing number of projects at work. What we did was quite clever.
It solved the requirement for: (a) multiple developers on the same development machine (b) automated urls for development and staging (c) near-instant adding of a new project (d) apache virtual host file auto-generation (e) providing local variables to PHP and Python, auto-generated based on the environment. (f) fine tuned control over mod rewrite and other apache configuration directives. We call it ConfTree, and it's written in Python. Essentially, you place _Twig.py files in your project (one or more), and define variables, which in turn get incorporated into a tree structure, and serialized to a xml file. Concurrently, based on a simple template, AutoConf/Local.py is generated, containing important project variables, like Database_Host. Then, access them from your project like this: from .Local import Database_Host In our project structure, we have a directory called AutoConf, of who's contents are ignored by version control. This is where we place auto-generated files that are different per instance of the project. Lastly, a bundled program is used to automatically read all of the xml files from all of the projects that a given instance of apache is to serve, generate 100% correct <VirtualHost> directives (with anything else that is needed), check the configuration (service httpd configtest), and restart apache if all is ok. In summary, we solved the very problem you are discussing. Let me know if you want the code, etc... I'll provide it under BSD. Thanks! Jason Garber On Sat, Jan 9, 2010 at 8:57 AM, GJ <[email protected]> wrote: > Thanks for the reply, Jason. > > Seems like I need to configure a separate WSGIDaemonProcess for each > project manually in the server configuration file if I want them to > have different python-path. This is not very nice when I have lots of > different projects and I cannot create new ones dynamically since I > would need to go edit the main configuration file each time. > > Or then I could direct the daemon process to include the parent > directory to the path and edit all existing scripts to import their > modules as "import this_project.module as module" instead of directly > "import module", but then use WSGIApplicationGroup with environment > variable to separate their execution to different interpreters since I > can use SetEnv in .htaccess files. This approach would make it more > dynamic and creating new projects just includes adding .htaccess file > with a single SetEnv directive to the project folder. The only > drawback is that I need to edit all existing scripts to change the way > they import their modules but since I need to edit them all anyway due > to changes I made to my web app platform, it's not a show stopper. > > Thank you, your reply gave me the ideas I needed. I'll try what I can > achieve with those directives. > > On Jan 9, 6:36 am, Jason Garber <[email protected]> wrote: > > Hello GJ, > > > > Here is a sample that we use to do *exactly* the same thing. Each > project > > has it's own Python directory which is added to the global python path > (for > > that project). > > > > See the WSGIApplicationGroup, WSGIDaemonProcess, and WSGIProcessGroup for > > information about why this works the way it does. > > > > *#Global Configuration* > > LoadModule wsgi_module modules/mod_wsgi.so > > WSGISocketPrefix run/wsgi > > WSGIApplicationGroup %{GLOBAL} > > > > *#Per Project Configuration* > > WSGIDaemonProcess ExampleProject threads=4 > > python-path=/opt/ExampleProject/Python > > <VirtualHost *> > > ServerName ExampleProject.com > > DocumentRoot /opt/ExampleProject/Web > > WSGIScriptAlias /User /opt/ExampleProject/app.wsgi > > WSGIScriptAlias /Home /opt/ExampleProject/app.wsgi > > WSGIProcessGroup ExampleProject > > LogLevel info > > ErrorLog /opt/ExampleProject/Log/apache-error.log > > </VirtualHost> > > > > Sincerely, > > Jason Garber > > > > > > > > On Fri, Jan 8, 2010 at 3:55 PM, GJ <[email protected]> wrote: > > > Hello, I decided to move away from using CGI directly to using WSGI on > > > my own web application platform. > > > > > I have just started with WSGI and have tried to read through the > > > configuration guides of mod_wsgi, but I have not found out how exactly > > > I should configure it on my server to best suit my needs, so I hope I > > > can get some better assistance here by asking. > > > > > So on my server I have multiple different small Python-based web > > > applications (all made by myself using a common Python web app > > > platform I am making), each on their own directories. Most of them > > > consist of more than one script file that are to be executed on HTTP > > > request and share some parts between the scripts, so they try to > > > import common files such as configurations. Since these files are part > > > of the projects themselves, they should not be visible to other > > > projects and therefore reside in the same location as the scripts > > > themselves. > > > > > Now the problem is that by default mod_wsgi does not let scripts > > > import modules that reside on the same directory as the script itself > > > but only from locations listed in sys.path. I read some previous > > > discussions about this and there are workarounds such as appending the > > > path of the current module to sys.path but as explained there are > > > problems such as there could be modules named the exact same in > > > different locations, as is the case with me. > > > > > Reading the configuration directives there were some things that allow > > > grouping of some scripts to work in the same process/thread, and let > > > other groups executed in different context. However, it was not clear > > > what directives I should use from the configuration to achieve what I > > > want: to separate each project to be its own group for mod_wsgi and > > > add the project's folder to path for that group. > > > > > Currently as I am developing the projects and testing them I am using > > > mod_wsgi in daemon mode with two processes and 5 threads each, but > > > depending on how much usage there will be in future, I will naturally > > > adjust them accordingly. > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "modwsgi" group. > > > To post to this group, send email to [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]<modwsgi%[email protected]> > <modwsgi%[email protected]<modwsgi%[email protected]> > > > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/modwsgi?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<modwsgi%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/modwsgi?hl=en. > > > >--
You received this message because you are subscribed to the Google Groups "modwsgi" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to [email protected].
For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
