On 08/11/2014, at 1:21 AM, Jon Flash <funksw...@gmail.com> wrote: > I am using 'mod_wsgi' express version with my Django application(s). I was > wondering if there is any documentation for the 'mod_wsgi.server' > INSTALLED_APP.
What in particular are you wanting to know about it? The 'mod_wsgi.server' package is only available if you have done a pip install of 'mod_wsgi' and so installed the mod_wsgi-express script as well. The mod_wsgi.server package mainly exists to support mod_wsgi-express and so also the runmodwsgi management command for Django manage.py when 'mod_wsgi.server' is listed in the installed applications as it uses the same underlying mechanism to configure and launch Apache. The latter works by 'mod_wsgi.server' package having a 'management' sub package which Django looks for management commands to extend what is available for manage.py. There is only minimal documentation for mod_wsgi-express at this point and it can be found at: https://pypi.python.org/pypi/mod_wsgi You can also find descriptions of each command line option to 'start-server' of mod_wsgi-express by running: mod_wsgi-express start-server --help Documentation is lacking right now as I am treating mod_wsgi-express as a bit of a fun project to get myself interested in working on mod_wsgi again after having neglected it for quite some time. Granted I haven't said much publicly about mod_wsgi-express, there also hasn't been a great deal of interest in it yet either to make me feel motivated to focus on the documentation. > Also what are the downsides to using mod_wsgi express in production vs the > traditional mod_wsgi / Apache installation. The main downside is that how mod_wsgi-express is installed and how it is used will upset system administrators who are overly paranoid and only trust binary packages that come with their operating system. They will also be upset because they are taken out of the loop as far as having to configure Apache themselves, so they will feel that they are loosing a measure of control and so will push back on any desire to use it. Personally I would argue this actually can be a good thing. The first reason why is that binary packages for the Linux distributions are generally woeful out of date. Most of the popular Linux distributions still only ship with mod_wsgi version 3.3 or 3.4 where as the latest version is 4.3.2. So they are more than 16 releases behind. Their argument in using binary packages from the Linux distribution is that they are supported if a LTS release of that Linux variant. That is actually mostly a load of nonsense as I don't personally actively maintain older mod_wsgi versions and the Linux distributions certainly don't. The versions they ship therefore carry bugs which could cause you problems and deny you from using features in newer versions which could make your life easier. But then they will say that the older versions will get security updates. That also is not entirely true. They may get a security fix, but that will only occur if a CERT advisory has been raised and a fix can even be back ported. Even if a CERT advisory is raised, for third party packages like mod_wsgi I know from experience that Linux distributions can take up to 6 months to get around to actually updating the binary package. So the idea that binary packages are somehow better in some way because of a quick turn around on security fixes is a bit of a fallacy. This may be true for main line core packages, but for third party packages they get very little love and you can actually be putting yourself in a bad position by not building the latest from source code yourself. The second reason is I see too many Apache configurations which are done quite badly. You will see some where people feel that the defaults are no good and start over with an empty config believing they can do better. In doing that though, they immediately throw away some of the security that the defaults provide. Even when people retain the default Apache configuration, that defaults are always tailored to static or PHP sites and so the performance for a Python web site can be quite bad as a result and a lot more resources used up than need be if things were setup right for a Python web site. So mod_wsgi-express rather than having downsides, is actually meant to improve on the sad state of affairs that can quite often exist. The idea with mod_wsgi-express is that through my experience of Apache and what makes a good configuration for Python web hosting, I can generate the configuration automatically for you. This approach will probably work for a good majority of people who are running a Python web site. It will not work for everyone though, especially where an Apache instances is shared for other purposes, and in those cases you would still have to fall back to configuring an existing Apache installation yourself. Overall the aim of mod_wsgi-express is to provide a minimal amount of options which will satisfy the needs of 90% of the people out there. This is in contrast to some other WSGI hosting solutions where 90% of the options are totally irrelevant and just make it hard to find what you do need. This is not to say that everything is in place to make it as easy as possible to use mod_wsgi-express. One thing that still needs to be done is the automatic generation of system start scripts which could then be quickly integrated into a Linux system to get things running. Due to my lack of knowledge of different Linux systems this is where I will need some help, but although I put a call out a while ago for help in this area, I got no responses. That is therefore something which will come only slowly at this point as I want to focus on other areas for the time being. Graham -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to modwsgi+unsubscr...@googlegroups.com. To post to this group, send email to modwsgi@googlegroups.com. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.