Thanks for the update, and good luck! On Sun, Jan 10, 2010 at 6:45 AM, GJ <[email protected]> wrote:
> 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]<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.
