Re: common variable (Deploying Feature in manage.py)

[Javier Guerra Giraldez]

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: common variable (Deploying Feature in manage.py)

[Tom Evans]

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)

[Jonathan Slenders]

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.

common variable (Deploying Feature in manage.py)

[Thomas Guettler]

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

[Jonathan Slenders]

On Oct 24, 2:18 pm, Markus Gattol  wrote:
> 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

[Markus Gattol]

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

[Gabriel Hurley]

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

[Aymeric Augustin]

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

[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

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.