Message from discussion
common variable (Deploying Feature in manage.py)
Received: by 10.52.30.195 with SMTP id u3mr26744604vdh.3.1319550978860;
Tue, 25 Oct 2011 06:56:18 -0700 (PDT)
X-BeenThere: django-developers@googlegroups.com
Received: by 10.220.99.207 with SMTP id v15ls37076vcn.2.canary; Tue, 25 Oct
2011 06:56:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.7.11 with SMTP id b11mr9187vcb.32.1319550969973; Tue, 25
Oct 2011 06:56:09 -0700 (PDT)
Received: by f11g2000vbm.googlegroups.com with HTTP; Tue, 25 Oct 2011 06:56:09
-0700 (PDT)
Date: Tue, 25 Oct 2011 06:56:09 -0700 (PDT)
In-Reply-To: <4EA6AB78.3030109@tbz-pariv.de>
References: <49e371b3-829d-4075-849d-402438d380a8@gy7g2000vbb.googlegroups.com>
<4EA6AB78.3030109@tbz-pariv.de>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/534.24 (KHTML,
like Gecko) Chrome/11.0.696.57 Safari/534.24,gzip(gfe)
Message-ID: <8f5e10a8-15d4-447b-a376-e3e985dbb8f0@f11g2000vbm.googlegroups.com>
Subject: Re: common variable (Deploying Feature in manage.py)
From: Jonathan Slenders <jonathan.slend...@gmail.com>
To: Django developers <django-developers@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 25 oct, 14:28, Thomas Guettler <h...@tbz-pariv.de> wrote:
> I would like to see a common variable in django's settings:
> =A0STAGE=3D...
> =A0with one of this choices: DEV, INTEGRATION, QUAL, PROD
>
> It would be nice, if the django core could agree on a variable name and i=
ts content.
> Several deploy apps could use this common variable.
>
> In our company we have a common variable. PROD is zero:
>
> if STAGE:
> =A0 =A0 # some dev system...
Me too. We use CONFIG_DEV=3D'dev', CONFIG_PROD=3D'prod',
CONFIG_BETA=3D'beta' and then assign one of these three to
settings.CONFIG. Our deployment app used to replace CONFIG=3DCONFIG_DEV
by CONFIG=3DCONFIG_PROD
It would be good to agree on a naming convension for this.
However,... on newer applications, our deployment app does automatic
generation the parts from the settings (like IP addresses) which are
in production different from the development settings.
The question is, should a git/gh/... repository contain any production
specific settings? (Assuming one is using a vcs checkout.) Deployment
scripts are perfectly capable of replacing the config with production
settings right after the checkout.
Further, I think that applications should be agnostic about in what
environment they run. They should never behave different locally, in
stage or in production. You have settings which contains IP addresses,
DEBUG=3DTrue/False, etc... but I think they don't have to know whether
they run in production or not. The only reason for such a variable to
exists, may be to decide between several other settings to include.
Correct me if you think differently.
Cheers,
Jonathan