That sounds like a bit too much for my needs. Anyway, thanks for the
offer, Jason, I appreciate it.
So far it seems that my configuration is working quite well the way I
want it to. It's not perfect and what I originally envisioned but at
least for now is sufficient. If I need to go as far as to
automatically generate Apache configuration files, then I can do that
myself (and probably a little more lightweight than your system).
Just for reference I'll post my current configuration here, in the
hope that someone else pondering with the same question I originally
had happens to stumble upon this discussion and could find some help
out of this.
<VirtualHost *:80>
...
WSGIDaemonProcess mydomain|/py processes=2 threads=5 python-path=/
var/www/py maximum-requests=1000 inactivity-timeout=600
<Directory /var/www/py/*>
WSGIProcessGroup mydomain|/py
WSGIApplicationGroup %{ENV:WSGI_APPLICATION_GROUP}
SetEnv WSGI_APPLICATION_GROUP _unassigned
AllowOverride FileInfo
Options ExecCGI FollowSymLinks
SetHandler wsgi-script
RedirectMatch permanent ^/py/([a-z]+)/$ /py/$1/index.wsgi
Order allow,deny
Allow from all
</Directory>
...
</VirtualHost>
Essentially what I do is set one process group for all projects under
the "py" directory, leaving possibility to add other process groups in
future if needed. For this process group I set application group to be
whatever environment variable WSGI_APPLICATION_GROUP is. I set it to
be _unassigned, but with AllowOverride FileInfo I can set it per-
project with .htaccess files.
This way small one or two file projects that can safely co-exist are
all run in _unassigned scope while some bigger projects get their own
application groups named by their .htaccess files. Since the projects
are small and do not have heavy usage, a single process group is
enough for them all for now.
If one of the projects there ever get so big and heavy usage that it
warrants a dedicated process group, then I can create one here and
change the WSGIProcessGroup also use environment variable that I can
set in .htaccess file to set a specific project to execute in its own
group of processes.
The original problem of not being able to import modules from the
script's own folder is partly solved by having the process group add
common parent folder to Python path and in the scripts do "import
project.module as module".
Someone might say that having the scripts under /var/www directly is a
bad idea for security, being concerned that their source codes could
be readable. That's OK for me since one of the projects is a file
browser that is used to view the source codes of the projects ;)
In any case, thank you Jason for the ideas. For now I guess I'll
manage on my own but it's good to know that there exists a discussion
group with helpful people around if I have something to ask again.
Cheers,
Joonas Lehtolahti
On Jan 10, 5:54 am, Jason Garber <[email protected]> wrote:
> 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
>
--
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.
