Graham Dumpleton wrote:
>
> On Mar 30, 7:17 am, Jose Galvez <[email protected]> wrote:
>   
>> Wow this discussion has been really great, I've learned quite a bit just
>> following the different threads.  Like I said I think there is room in
>> the wiki for us to post better real world howto's with end to end config
>> files.  For example I could post my:
>> 1) init script for supervisord (although I think the one Mike posted is
>> better then mine so I'll most likely edit mine
>> 2) the section in my supervisord.conf file
>> 3) the sections in my apache conf files
>>
>> I would like to see the same thing from Max on how he did it with nginx
>> and monit, and how Graham is serving his stuff with mod_wsgi.  As
>> mentioned in one of the posts mod_wsgi could use some better
>> documentation and this might be a good way to do that.
>>     
>
> Do you mean better mod_wsgi documentation as part of the Pylons
> documentation, or that mod_wsgi itself needs better/more
> documentation?
>   
I guess I mean better or more complete example is probably a better 
choice of words rather then documentation because as you already 
mentioned mod_wsgi has good docs

> There is already quite a lot of documentation on mod_wsgi. It could be
> a bit better indexed but if one follows the main entry points from the
> mod_wsgi main page, it will get you to most stuff.
>
>   http://code.google.com/p/modwsgi/wiki/InstallationInstructions
>   http://code.google.com/p/modwsgi/wiki/DeveloperGuidelines
>
> The index of everything is at:
>
>   http://code.google.com/p/modwsgi/w/list
>
> The main ones pertinent to Pylons are:
>
>   http://code.google.com/p/modwsgi/wiki/IntegrationWithPylons
>   http://code.google.com/p/modwsgi/wiki/VirtualEnvironments
>
> There is also some information in the online Pylons book, although
> that does have at least one mistake in claiming that EvalException
> cannot be used with mod_wsgi. You just need to make sure you are
> running daemon mode with a single process. That is also mentioned in
> documentation:
>
>   
> http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Browser_Based_Debugger
>
> Graham
>
>   
>> Max also mentions upstartn, whats the advantage to that over using the
>> system V script?
>>
>> Jose
>>
>> jose wrote:
>>     
>>> HI all, Just thought I would share what I've learned deploying pylons
>>> on both windows and linux loxes.  First let me say right off the bat I
>>> absolutely love pylons I think hands down its the absolutely best web
>>> development environment out there.  Having said that the biggest issue
>>> I see with pylons and wsgi apps in general, really has nothing to do
>>> with their ability to function as a framework,  but its deployment.
>>> Now before anyone goes all "read the wiki" "read the docs" on me, I
>>> have so the rest of this is just my experience setting up pylons to
>>> run with Apache on both windows and linux (Ubuntu specifically).  Now
>>> I love choices and if you want to connect your new pylons app to run
>>> under apache you do have several, mod_wsgi, fastcgi, scgi, mod_python,
>>> and the ever present mod_proxy, and I've tried them all.  For my
>>> money, both in terms of simplicity and in terms of development cycles
>>> mod_proxy is by far the easiest and I would venture to say the most
>>> stable.  I did use mod_wsgi for a while, and will most likely use it
>>> on a limited project where running a pylons long running appp will be
>>> problematic, but mod_proxy just offers so much in the way of
>>> flexibility. Not to mention the fact that I just hate restarting
>>> apache just because I've made some minor change to one of my
>>> controllers.
>>>       
>>> So this brings me to the heart of what I've learned, if you are going
>>> to deploy a long running app how do you do it?  On Windows the best
>>> solution I've come up with is my own Bourbon project, which I admit
>>> has all but died (I would love to give the code to someone to run
>>> with, I just really don't have the time to maintain it any longer).
>>> The reason I wrote it in the first place was allow give me a single
>>> windows service to manage all my running pylons apps without having to
>>> give each and every one its own windows service, which is a pain.
>>> Bourbon works pretty good, but at the moment you can't turn off or
>>> restart a single app, its all or nothing, which isn't very good.
>>>       
>>> On Linux its a different story, there are a tun of ways to get a long
>>> running application up and running, and to some extent it depends on
>>> what distro you are using as to which is the best.  On ubuntu I
>>> initially thought of writing rc init scripts for each app, but this
>>> quickly turned into a task that I didn't want to deal with, so I
>>> turned to mod_wsgi, which as I stated above for philosophical reasons
>>> I just didn't like.  The I found, ok more likely stumbled upon after
>>> reading the wiki, supervisord.  Finally something that makes sense (at
>>> least to me it really does).  Now, after writing only a single rc init
>>> script to get supervisord running my pylons apps (and almost anything
>>> else I might have to start as a a daemon for that matter) is easily
>>> configured to run under the supervisord.conf file.  I just love that
>>> thing.  I know a best practices section goes against the grain for the
>>> pylons community because it is all about flexibility,  but what about
>>> a series of deployment scenario's, where people could write how they
>>> are actually doing this stuff.  I know its already all there if you
>>> look for it, but this has taken me while to put together for myself
>>> and I'm sure there are others out there who could learn from our
>>> growing pains
>>>       
> >
>
>   

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" 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/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to