Re: common variable (Deploying Feature in manage.py)
On Tue, Oct 25, 2011 at 9:29 AM, Tom Evanswrote: > 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: common variable (Deploying Feature in manage.py)
On Tue, Oct 25, 2011 at 1:28 PM, Thomas Guettlerwrote: > 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 25 oct, 14:28, Thomas Guettlerwrote: > 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.
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: Deploying Feature in manage.py
On Oct 24, 2:18 pm, Markus Gattolwrote: > I agree with others that this is better left to tools such as fabric/cuisine > as they are build to handle these kind of > tasks:http://readthedocs.org/docs/fabric/en/latest/api/contrib/project.html There's indeed no generic way of deploying for everyone... I'm currently finishing a new deployment framework at my company (Mobile Vikings), inspired by fabric and also based upon Paramiko (the SSH) library. (It is not to reinvent Fabric, but we just needed our deployments to be more flexibility/powerful. That is as declarative as possible, readable, DRY and having reusable components, taking care of cross-server dependencies/references, undo where possible, having a deployment shell with autocomplete, easy beta/staging duplication, and more...) If everything goes well and I'm confident, we will place the stable source code on github and I'll post a link in django-users -- hopefully somewhere within the following two weeks. By the way, any input of what you think a deployment tool should have, or what you think that other tools lack is welcome. (send me in PM) 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: Deploying Feature in manage.py
I agree with others that this is better left to tools such as fabric/cuisine as they are build to handle these kind of tasks: http://readthedocs.org/docs/fabric/en/latest/api/contrib/project.html -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/uwCmcgoVlKcJ. 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: Deploying Feature in manage.py
Having done deployments of varying scales and having spent a lot of time with Fabric, as well as some with Chef, Puppet, etc. I don't think there's any way we can build a tool that will meet any but the absolute simplest of needs without unnecessarily re-inventing a lot of wheels. However, if you're interested in pursuing this project then this is a great space for a 3rd-party app that ties in the features you'd like to see as management commands. There's absolutely no reason this needs to live in core and if it gains traction with the community then I could see it being a wonderfully useful asset. All the best, - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/uidNz6GYzn8J. 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: Deploying Feature in manage.py
On 23 oct. 2011, at 21:59, feel wrote: > 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. Hi Filippo, I'm not convinced we can build a sufficiently useful and generic solution on this basis. For instance, many people prefer going through a (D)VCS rather than copying files directly between the development and production machines — it becomes necessary as soon as there's more than one developer. Furthermore, it's a different kind of program (systems administration, not web development) and there's no advantage to tie it to manage.py. For these reasons, it don't think it's a good idea to include this feature in Django. Standalone tools such as Fabric are designed just to address this problem space; you can probably find one that will suit your needs. Thanks for the suggestion anyway! -- Aymeric Augustin. -- 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.
Deploying Feature in manage.py
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 So, just typing: ./manage.py deploy --test We simulate the synchronization, while: ./manage.py deploy It'll sync all data in the remote folder. It get the parameters of the local directory, remote directory, ip server, etc in settings.py and automatically sync the remote server. He helped me a lot in particular because you don't have to think about modifying file in remote folder but every modification will be applied always in local. In this case I created a new command for manage.py but It would be nice if it was in django directly. Of course, my solution must be improved trying to get rid the dependency with rsync and to work well in windows too. Another improvement could be the exclude option if someone want to manage manually some files of his own project. How do you consider that propose?? Do you think it could be applied a new ticket feature for it?? Thanks -- 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.