Re: Main Application's settings.py floating multiple systems

2011-03-07 Thread Cal Leeming [Simplicity Media Ltd]
On Mon, Mar 7, 2011 at 10:51 PM, Mike Ramirez wrote: > On Monday, March 07, 2011 01:20:47 pm Cal Leeming [Simplicity Media Ltd] > wrote: > > > I wouldn't recommend using this method, I did this previously for several > > > months, and quickly switched to an alternative

Re: Main Application's settings.py floating multiple systems

2011-03-07 Thread Mike Ramirez
On Monday, March 07, 2011 01:20:47 pm Cal Leeming [Simplicity Media Ltd] wrote: > I wouldn't recommend using this method, I did this previously for several > months, and quickly switched to an alternative (which I mentioned in my > previous post). > > Generally speaking, keeping anything outside

Re: Main Application's settings.py floating multiple systems

2011-03-07 Thread Shawn Milochik
I really need to pay attention to whom incoming e-mail is addressed. I thought I was continuing the thread on the list. Shawn -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com.

Re: Main Application's settings.py floating multiple systems

2011-03-07 Thread Cal Leeming [Simplicity Media Ltd]
I guess it depends on what you need to do. The webapps we run here have to meet a "high availability" criteria where it can float between nodes without experiencing any problems, whilst keeping a clear separation between dev, staging (if needed) and production environments. Our webapps are also

Re: Main Application's settings.py floating multiple systems

2011-03-07 Thread Cal Leeming [Simplicity Media Ltd]
I wouldn't recommend using this method, I did this previously for several months, and quickly switched to an alternative (which I mentioned in my previous post). Generally speaking, keeping anything outside of the version control is just not a good idea, unless it's a tmpfs, a sock dir, or

Re: Main Application's settings.py floating multiple systems

2011-03-07 Thread Shawn Milochik
The easiest solution I've found: 1. Create a file named local_settings.py that is *outside* of version control. 2. Import local_settings at the bottom of settings.py, handling the exception if it doesn't exist. 3. Override anything you like in local_settings.py. This has these

Re: Main Application's settings.py floating multiple systems

2011-03-07 Thread Cal Leeming [Simplicity Media Ltd]
Oh I also added DJANGO_ENVIRONMENT into that, which lets you specify environmental based settings overrides from the command line. Enjoy :) On Mon, Mar 7, 2011 at 9:09 PM, Cal Leeming [Simplicity Media Ltd] < cal.leem...@simplicitymedialtd.co.uk> wrote: > Hi, > > Omg, I was *just* thinking

Re: Main Application's settings.py floating multiple systems

2011-03-07 Thread Cal Leeming [Simplicity Media Ltd]
Hi, Omg, I was *just* thinking about whether I should do a blog entry about this sort of requirement lmao. To combat multiple node hosting, we use a combination of code (as our webapps are split over multiple servers, all of which have different functions and varying environments) Here is a

Re: Main Application's settings.py floating multiple systems

2011-03-07 Thread Michael Radziej
On Mon, 7 Mar 2011 10:26:53 -0800 (PST), octopusgrabbus wrote: > So, my question is, is there an accepted way to populate BASE_URL and > MEDIA_URL with some local setting, like perhaps calling a python > function?, because it's Python code? I usually have a set of

Main Application's settings.py floating multiple systems

2011-03-07 Thread octopusgrabbus
Is there a standard, accepted way to use environment variable or other substitution, so the application's settings.py file can exist on, for example, a production and test system. Right now, I've taken to coding the URL strings separately, and I know that's bad in the long run. So, my question