common variable (Deploying Feature in manage.py)
Am 23.10.2011 21:59, schrieb feel: > Hi, I wanted to propose a new possible feature in Django project that > allows to sync the local folder with the remote one of the server > defining all the configuration directly in settings.py. > > I've just done some months ago a simple implementation using rsync and > I reported it in active state: > http://code.activestate.com/recipes/577767-managment-command-to-deploy-a-django-project/?in=user-4174931 Hi, I won't use rsync. Code should not be altered on the server but sometimes you (or someone else) does it. Rsync would overwrite it. Up to now I use unison, but there are better solutions. I would like to see a common variable in django's settings: STAGE=... with one of this choices: DEV, INTEGRATION, QUAL, PROD It would be nice, if the django core could agree on a variable name and its content. Several deploy apps could use this common variable. In our company we have a common variable. PROD is zero: if STAGE: # some dev system... -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: common variable (Deploying Feature in manage.py)
On 25 oct, 14:28, Thomas Guettler wrote: > I would like to see a common variable in django's settings: > STAGE=... > with one of this choices: DEV, INTEGRATION, QUAL, PROD > > It would be nice, if the django core could agree on a variable name and its > content. > Several deploy apps could use this common variable. > > In our company we have a common variable. PROD is zero: > > if STAGE: > # some dev system... Me too. We use CONFIG_DEV='dev', CONFIG_PROD='prod', CONFIG_BETA='beta' and then assign one of these three to settings.CONFIG. Our deployment app used to replace CONFIG=CONFIG_DEV by CONFIG=CONFIG_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=True/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 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: common variable (Deploying Feature in manage.py)
On Tue, Oct 25, 2011 at 1:28 PM, Thomas Guettler wrote: > Am 23.10.2011 21:59, schrieb feel: >> Hi, I wanted to propose a new possible feature in Django project that >> allows to sync the local folder with the remote one of the server >> defining all the configuration directly in settings.py. >> >> I've just done some months ago a simple implementation using rsync and >> I reported it in active state: >> http://code.activestate.com/recipes/577767-managment-command-to-deploy-a-django-project/?in=user-4174931 > > Hi, > > I won't use rsync. Code should not be altered on the server but sometimes you > (or someone else) does > it. Rsync would overwrite it. Up to now I use unison, but there are better > solutions. > > > I would like to see a common variable in django's settings: > STAGE=... > with one of this choices: DEV, INTEGRATION, QUAL, PROD > I honestly think that trying to integrate any sort of deployment features in django will only please the few people who use that particular method of deploying code, and irritate the majority who do it in a different manner. There is no 'correct' way of doing this, and trying to find a correct way inside of django itself will only lead to constant bike-shed discussions. If you are interested in improving deployment, I suggest that initially this is done outside of django. Once it is clear that your solution is THE standard, then the discussion about bringing it inside of django can begin (qv South). FYI at $JOB would never countenance a deployment using rsync/unison/scp/whatever. Each deployment is a fresh, unmodified checkout from a specific tag/branch of an RCS, and we never update a checkout - a completely fresh deployment is rolled for each update. The correct settings for each backend are baked in from the RCS, and are specific to each backend. Cheers Tom -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: common variable (Deploying Feature in manage.py)
On Tue, Oct 25, 2011 at 9:29 AM, Tom Evans wrote: > I honestly think that trying to integrate any sort of deployment > features in django will only please the few people who use that > particular method of deploying code, and irritate the majority who do > it in a different manner. There is no 'correct' way of doing this, and > trying to find a correct way inside of django itself will only lead to > constant bike-shed discussions. absolutely. I myself deploy Django apps in at least three different ways, each one for different situations. choosing any one as _the_ official, and replacing the others would be a downgrade for most cases. of course, it could be done; it might even be easier for me. but it's not what i've chosen. -- Javier -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Sane defaults for Startapp and Startproject
Having an example project to fork/fiddle with in the documentation is a fair compromise. svn co http://code.djangoproject.com/svn/django/trunk/ django-example ? R On Oct 21, 2:22 pm, Carl Meyer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi Rich, > > On 10/21/2011 10:21 AM, Rich Jones wrote: > > > How would you guys feel about a manage.py startexample > > > which would create an example application? A simple, templated hello > > world with an example model and an example view and an example > > template? > > Indifferent? I kinda feel like following the tutorial gives you this > already, and I'm not real excited about having another "sample project" > in core to maintain and update. OTOH I understand that a lot of people > learn best by tweaking existing working code, and if this were done > outside of core the people who most need it (beginners) are not likely > to be aware of it. Maybe there'd be a way to make it a downloadable part > of the docs rather than a management command? > > I'm not going to work on this or commit it, but if other people > (including at least one core dev) are excited about it I wouldn't stand > in the way. So I guess that's a -0. > > Carl > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/ > > iEYEARECAAYFAk6huGUACgkQ8W4rlRKtE2dAWQCg6mKdlRHDkk+sPYJvafjyms5C > Q2wAoN70oNfxh3vTzd4W7DqrUCzO/RD8 > =mCZ7 > -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
