On 17 April 2010 16:10, cd34 <[email protected]> wrote: > On Apr 16, 11:17 pm, Graham Dumpleton <[email protected]> > wrote: >> For virtual environments read: >> >> http://code.google.com/p/modwsgi/wiki/VirtualEnvironments >> >> What you are doing is not sufficient. > > As pylons now sets the egg cache, I didn't see why it was needed to > reset it.
What do you mean that Pylons sets it? Even the documentation at: http://pylonsbook.com/en/1.1/deployment.html#setting-up-a-virtual-host has an example which explicitly sets it. > As it stands, the documentation on the mod_wsgi wiki > doesn't work. The suggested config from > http://pylonsbook.com/en/1.1/deployment.html#setting-up-a-virtual-host > worked as long as the system Python was the same version as the > virtualenv. It did not work on a system where python had been > upgraded, but the virtualenv had not been. If it was a different major/minor version of Python, that obviously will not work. This is because a virtualenv is a standalone Python installation, it just refers to the separately installed original Python installation. Thus if you upgrade the original installation and remove the old, the virtualenv will not be referring to anything. This isn't a mod_wsgi or Pylons issue. > Perhaps sys.path.insert would b > >> >> Also read: >> >> http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Browser_Bas... >> >> You can still have DEBUG be true, but you must run a configuration >> whereby all requests go to the same process. On UNIX boxes that means >> using daemon mode and allowing the default of one process to be used. >> Don't use 'processes=1' as that is a special case and still results in >> wsgi.multitoprocess being true, just leave the processes option out >> all together. > > I figured documenting issues people might... > > We'll just document things internally, sorry to have interrupted the > list. The documentation at: http://pylonsbook.com/en/1.1/deployment.html#setting-up-a-virtual-host mentions the debugger issue but is incomplete, giving the impression that only fixable by changing StartServers and ServerLimit. That is wrong as only applies to embedded mode. You can instead use daemon mode of mod_wsgi and allow it to use default of single daemon mode process. I have been wanting to get rid of the page: http://code.google.com/p/modwsgi/wiki/IntegrationWithPylons for a long time and refer to Pylons own documentation where they can maintain what to do, but frankly their documentation sucked the last time I looked at it and had various errors in it. I sent an email to Pylons list about issues in their documentation and my intention to drop my documentation, but there was zero responses. The Pylons folks seem to only really care about Paste server and most will always tell you to avoid mod_wsgi. Anyway, it appears their documentation has been updated since last time I looked, so maybe I can finally remove the page for mod_wsgi documentation. Although it still doesn't refer to virtual environments documentation and wrongly says that site.addsitedir() is enough. Why do I want to remove it. Because I don't use Pylons and so I don't know all the tricks that are required to get it to work. I also cant keep up to date with changes made in Pylons to ensure it is always up to date. This isn't anything specific against Pylons as want to drop all the integration guides and refer to frameworks own documentation on the matter, but other frameworks documentation isn't any better and similarly can't usually get responses seeing if they will integrate bits of my documentation into theirs and then maintain full documentation themselves. Crappy documentation on how to host frameworks on any sort of hosting is the norm for Python unfortunately. Many frameworks also don't put a great deal of effort into even making it easy to host their frameworks. Some don't even provide a decent WSGI application entry point that creates the same process environment as when development server is used. Thus you end up with all sorts of problems when you move to production environment. Graham -- 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.
