> Thanks Karen. Is annoying sometimes when you see people don't bother
> reading past the single mod_wsgi page on Django site even though I put
> disclaimers at front to try and encourage people to do so without
> making it too blatant that what I wanted to say was 'STOP BEING LAZY
> AND GO READ TH
On Nov 25, 6:43 pm, Crispin Wellington
wrote:
> On Tue, 2009-11-24 at 21:52 -0800, Graham Dumpleton wrote:
> > Your imagination is running amuck, no such thing happens. You can
> > quite happily run multiple Django instances in embedded mode, they
> > just need to be separated into distinct Pyth
On Tue, 2009-11-24 at 21:52 -0800, Graham Dumpleton wrote:
> Your imagination is running amuck, no such thing happens. You can
> quite happily run multiple Django instances in embedded mode, they
> just need to be separated into distinct Python sub interpreters, which
> is the default behaviour of
On Nov 25, 4:52 pm, Graham Dumpleton
wrote:
> On Nov 25, 3:23 pm, Crispin Wellington
>
> wrote:
> > Have a read of the mod_wsgi documentation, particularly the
> > page:http://code.google.com/p/modwsgi/wiki/ApplicationIssues
>
> > Because Django uses environment variables to access the setting
On Nov 25, 3:58 pm, Karen Tracey wrote:
> On Tue, Nov 24, 2009 at 11:32 PM, Tim Valenta
> wrote:
>
>
>
>
>
> > Yeah, production servers aren't really very friendly to changes.
> > Languages like PHP are specifically built to circumvent such woes.
> > You would have to actually bounce apache in
On Nov 25, 3:23 pm, Crispin Wellington
wrote:
> Have a read of the mod_wsgi documentation, particularly the
> page:http://code.google.com/p/modwsgi/wiki/ApplicationIssues
>
> Because Django uses environment variables to access the settings file,
> all kinds of strife can occur when running Djan
That is all really helpful; thanks very much everybody. My production
environment is Apache 2.2.9 on Fedora, so it looks as if the solution
Karen suggests will be workable, and I think I will give that a try as
it looks close to ideal.
Thanks again all; much appreciated.
Tom
--
You received th
On Tue, Nov 24, 2009 at 11:32 PM, Tim Valenta wrote:
> Yeah, production servers aren't really very friendly to changes.
> Languages like PHP are specifically built to circumvent such woes.
> You would have to actually bounce apache in order to get the changes
> to take.
>
> This is why the develop
Yeah, production servers aren't really very friendly to changes.
Languages like PHP are specifically built to circumvent such woes.
You would have to actually bounce apache in order to get the changes
to take.
This is why the development server is so nice, because when you alter
certain files that
Have a read of the mod_wsgi documentation, particularly the page:
http://code.google.com/p/modwsgi/wiki/ApplicationIssues
Because Django uses environment variables to access the settings file,
all kinds of strife can occur when running Django on top of mod_wsgi.
Essentially Django and mod_wsgi don
Sorry, I should have mentioned that this has only come up after
deploying the project to a production server using mod_wsgi. It works
absolutely fine under development.
Tom
On Nov 25, 2:24 am, Tim Valenta wrote:
> Are you using the development server? There's definitely caching
> funny-busines
Are you using the development server? There's definitely caching
funny-business in a production web server, but that should affect you
if you're using "manage.py runserver"
Does stopping and starting the development server change anything?
Tim
On Nov 24, 6:54 pm, Tom wrote:
> Hi all,
>
> I am
Hi all,
I am experiencing TemplateDoesNotExist errors. Initially I thought I
had my TEMPLATE_DIRS variable set incorrectly, but much
experimentation yielded nothing. I then noticed that on the browser
TemplateDoesNotExist error pages the TEMPLATE_DIRS setting reads as an
empty tuple (). I then
13 matches
Mail list logo
