Re: sys.exit(1) from makemigrations if no changes found

[Marc Tamlyn]

I agree number 1 is fine. For most general interaction with the command
users won't notice.

Marc
On 29 Oct 2014 02:04, "Andrew Godwin"  wrote:

> I'm actually fine with option 1 - always exiting with a status code if no
> migrations are found. Since the status code does nothing useful at the
> moment, I don't see any backwards compatibility issues, and as long as it's
> a suitably small patch, it should be fine.
>
> (As for being surprising compared to grep, there are many other commands
> with different exit codes one could draw parallels to; I'm not sure being
> consistent with a very different utility is a worthwhile cause).
>
> Andrew
>
> On Tue, Oct 28, 2014 at 6:22 PM, Tim Heap  wrote:
>
>> Hi all,
>>
>> I have created a ticket for this (
>> https://code.djangoproject.com/ticket/23728) but I would like some input
>> before I work on it. I will copy the content of the ticket below for ease
>> of reading:
>>
>> It would be very useful for continuous deployment, testing, commit hooks,
>> and other applications if django-admin makemigrations signaled via an
>> exit code if any migrations were found. Commits in projects could be
>> rejected if migrations were outstanding, continuous deployment systems
>> could fail the build on outstanding migrations, and potentially other uses.
>> No more would hasty commits break things when developers forgot to make
>> migrations!
>>
>> Changes to the code to make this happen are easy enough, but I am unsure
>> how the command should behave. The grep unix utility is a example to
>> copy. Under normal operation, grep always exits 0 unless an error
>> happens, regardless of whether it found any matches. Invoking grep with
>> the -q/--quiet flag causes grep to be silent, not printing anything, as
>> well as exiting 0 if matches are found and 1 if nothing is found.
>>
>> I am proposing django-admin makemigrations should exit with 1 (or
>> anything non-zero) if no migrations to make were found, or exit 0 if
>> migrations to make were found. As the command is instructed to make
>> migrations, not making any is the error case.
>>
>> I am unsure how this new functionality should be selected by the user
>> when invoking makemigrations. The options I see are:
>>
>>1. Enable this always. This is very simple to implement and easy to
>>understand. Good unixy tools use error codes extensively to signal errors.
>>This may be surprising behaviour when compared to grep though, and breaks
>>backwards compatibility in a minor way.
>>2. Enable this when the --dry-run flag is enabled. Now this flag can
>>be used to check for migrations that need to be created both visually via
>>the printed text, and composed in shell commands.
>>3. Add a new flag -e/--exit (or similar). The sole purpose of this
>>flag would be to exit with 1 when no migrations were found. This could be
>>combined with --dry-run to just check for migrations that need to be
>>made.
>>4. Add a new flag -q/--quiet that copies the behaviour of greps
>>-q/--quiet flag: silences output and exits with 1 when no migrations
>>were found. This duplicates functionality though, as logging can be
>>silenced using -v0 already.
>>
>> My personal preference is for option 2. I was surprised when enabling
>> --dry-run did not signal its result via the exit code. 3 would be the
>> cleanest and most composable option, as 4 could be emulated using -ev0.
>>
>> I will implement this change using 2, unless other people have opinions
>> on the matter.
>>
>> Regards,
>> Tim
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/92203dcb-a775-4c17-a831-97d01ce8af3c%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAFwN1up96C8Daxn87Mt1y-TY%3DvGP_%3DTGaBRH6NZ9s5AQUu%3DL0A%40mail.gmail.com
> 

Re: Websockets... again

[Florian Apolloner]

On Tuesday, October 28, 2014 11:37:15 PM UTC+1, mpaolini wrote:
>
> What if we do it with asyncio?
>

It is 3.4 only, WSGI still has no support for Websockets and the API would 
change drastically… 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/890fc65e-21b5-4104-947d-c16e56b3315f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Websockets... again

[Aymeric Augustin]

Then the first step is to throw away the ORM.

See my talk at DjangoCon US 2013 for details.

-- 
Aymeric.

> Le 28 oct. 2014 à 23:36, Marco Paolini  a écrit :
> 
> What if we do it with asyncio?
> 
> 2014-10-28 22:47 GMT+01:00 Aymeric Augustin 
> :
>> No, there isn’t.
>> 
>> I assume that “including in core” means at least “making usable in 
>> combination with WSGI and with the ORM”.
>> 
>> Even if we disregard for a minute the fact that WSGI is incompatible with 
>> websockets, the ORM is a hard problem, because current solutions involve 
>> either (a) threads — not particularly scalable or (b) gevent — not 
>> particularly reliable.
>> 
>> -- 
>> Aymeric.
>> 
>> 
>> 
>>> On 28 oct. 2014, at 22:06, Luis Masuelli  wrote:
>>> 
>>> Is there any current development involving including websockets in django 
>>> core?
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to django-developers+unsubscr...@googlegroups.com.
>>> To post to this group, send email to django-developers@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/50768d16-1d05-489c-8cbf-2091d95ff388%40googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/7D3898D4-50F7-4ACE-A081-0ACC9D824191%40polytechnique.org.
>> 
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAEbA68mnak1zdeAjTXM-Qfbz9mm%2B07qhfxZPCJPDfLFqHtcgpg%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/EEDD3BFA-B071-4FC4-93C7-0994E073D93B%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Overwrite mode in collectstatic

[Prathik Rajendran M]

Hi all,

This is to initiate a discussion on whether we should add a new overwrite 
method to collectstatic.

Although I agree that we should careful in adding new features, I think 
this one is pretty useful.

Here is why:

   - We want the files in STATIC_ROOT to be replaced even if the one there 
   is newer. Currently I don't see a way to do this apart from using --clear 
   which deletes the entire directory, where other apps could be writing too. 
   We could implement overwrite where it does a filecmp and then overwrites.
   - The clear method deletes the files irrespective of where they are, an 
   accident could mean that data could be lost for ever. In one instance our 
   production box had STATIC_ROOT point to a folder in the app accidentally, 
   then collectstatic was not fetching a file from a sub app which was linked 
   to the main project, we ran collectstatic --clear and it deleted the static 
   folder of the main project which had some base css/js files. This could 
   have brought down production for a while if not for a caching mechanism.
   - Django should be able to run in a safe mode where no unintended 
   side-effects should happen.

What are your thoughts on this?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0299af3f-c45a-4e51-b5ae-11b71f84b83d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Overwrite mode in collectstatic

[Tim Graham]

For other readers, my analysis of the issue and why I don't think it's 
appropriate can be found on the ticket where the idea was first raised: 
https://code.djangoproject.com/ticket/23724

On Wednesday, October 29, 2014 11:34:02 AM UTC-4, Prathik Rajendran M wrote:
>
> Hi all,
>
> This is to initiate a discussion on whether we should add a new overwrite 
> method to collectstatic.
>
> Although I agree that we should careful in adding new features, I think 
> this one is pretty useful.
>
> Here is why:
>
>- We want the files in STATIC_ROOT to be replaced even if the one 
>there is newer. Currently I don't see a way to do this apart from using 
>--clear which deletes the entire directory, where other apps could be 
>writing too. We could implement overwrite where it does a filecmp and then 
>overwrites.
>- The clear method deletes the files irrespective of where they are, 
>an accident could mean that data could be lost for ever. In one instance 
>our production box had STATIC_ROOT point to a folder in the app 
>accidentally, then collectstatic was not fetching a file from a sub app 
>which was linked to the main project, we ran collectstatic --clear and it 
>deleted the static folder of the main project which had some base css/js 
>files. This could have brought down production for a while if not for a 
>caching mechanism.
>- Django should be able to run in a safe mode where no unintended 
>side-effects should happen.
>
> What are your thoughts on this?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e16d9821-95ca-43c8-930b-3e05f3a447d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django query in DetailView

[Ronaldo Bahia]

*This question is also in 
http://stackoverflow.com/questions/26635406/django-query-in-detailview

I have DetailVIew wich returns a list of related objects (m2m throught). It 
works just fine!

But I need to search for objects'names and it is returning all objects 
instead of only the related ones.

How can I approach this?

Thanks.

#models.pyclass Candidate(models.Model):
user = models.OneToOneField(User, primary_key=True)
birth = models.CharField(max_length=50)
...
class Job(models.Model):
candidate = models.ManyToManyField('Candidate', through='CandidateToJob')
title = models.CharField(max_length=500)
...
class CandidateToJob(models.Model):
job = models.ForeignKey(Job, related_name='applied_to')
candidate = models.ForeignKey(Candidate, related_name='from_user')
STATUS_CHOICES = (
   ('1', 'Not approved'),
   ('2', 'Approved'),
   ('3', 'Hired')
)
status = models.CharField(max_length=2, choices=STATUS_CHOICES)

My search query

 #views.py
 def get_query(query_string, search_fields):
query = None # Query to search for every search term
terms = normalize_query(query_string)
for term in terms:
or_query = None # Query to search for a given term in each field
for field_name in search_fields:
q = Q(**{"%s__icontains" % field_name: term})
if or_query is None:
or_query = q
else:
or_query = or_query | q
if query is None:
query = or_query
else:
query = query & or_query
return query
def searchcandidate(request, *args, **kwargs):
query_string = ''
found_entries = None
if ('q' in request.GET) and request.GET['q'].strip():
query_string = request.GET['q']
entry_query = get_query(query_string, ['candidate__user__first_name',   
 'candidate__user__last_name'])

found_entries = 
CandidateToJob.objects.filter(entry_query).order_by('-candidate')

return render_to_response('dashboard/candidates_results.html',
{ 'query_string': query_string, 'found_entries': found_entries },
context_instance=RequestContext(request)
)

The view with the list of objects(candidates)

class Screening(generic.DetailView):

model = Job
template_name = 'dashboard/screening.html'

def get_context_data(self, **kwargs):
context = super(Screening, self).get_context_data(**kwargs)
context['candidate_list'] = 
self.object.applied_to.all().order_by('candidate')
return context  

My urls

#urls.py
url(r'^dashboard/job/(?P\d+)/screening/$', views.Screening.as_view(), 
name='screening'),
url(r'^dashboard/job/(?P\d+)/screening/results/$', 
'companies.views.searchcandidate', name='searchcandidate'),

And the templates

#html for Screening(DetailView) in which works good



Buscar


{% for candidate in candidate_list %}
 {{ candidate }}{% endfor %}

The one in which is returning all objects instead of only the related ones

#html{% if found_entries %}
 {% for candidate in found_entries %}
  {{ candidate }}
 {% endfor %}{% endif %}

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ca40cf5c-4354-45e4-9457-5aee243e9657%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Overwrite mode in collectstatic

[Marc Tamlyn]

I'd be inclined to agree with Tim, this seems to simply be a less useful
version of --clear, for which the primary motivation was "we messed up".
On 29 Oct 2014 16:05, "Tim Graham"  wrote:

> For other readers, my analysis of the issue and why I don't think it's
> appropriate can be found on the ticket where the idea was first raised:
> https://code.djangoproject.com/ticket/23724
>
> On Wednesday, October 29, 2014 11:34:02 AM UTC-4, Prathik Rajendran M
> wrote:
>>
>> Hi all,
>>
>> This is to initiate a discussion on whether we should add a new overwrite
>> method to collectstatic.
>>
>> Although I agree that we should careful in adding new features, I think
>> this one is pretty useful.
>>
>> Here is why:
>>
>>- We want the files in STATIC_ROOT to be replaced even if the one
>>there is newer. Currently I don't see a way to do this apart from using
>>--clear which deletes the entire directory, where other apps could be
>>writing too. We could implement overwrite where it does a filecmp and then
>>overwrites.
>>- The clear method deletes the files irrespective of where they are,
>>an accident could mean that data could be lost for ever. In one instance
>>our production box had STATIC_ROOT point to a folder in the app
>>accidentally, then collectstatic was not fetching a file from a sub app
>>which was linked to the main project, we ran collectstatic --clear and it
>>deleted the static folder of the main project which had some base css/js
>>files. This could have brought down production for a while if not for a
>>caching mechanism.
>>- Django should be able to run in a safe mode where no unintended
>>side-effects should happen.
>>
>> What are your thoughts on this?
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/e16d9821-95ca-43c8-930b-3e05f3a447d0%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1GJSr8fzZF8Uu%2BHwfgnPnJa_%3DW1T56Qh%2BufJgzoWRRgKw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django query in DetailView

[Tom Christie]

Hi Ronaldo,

This list is for the discussion of development *on the Django project 
itself*,
not for discussion of usage questions when developing Django sites.

You want the django-users mailing list, 
here: https://groups.google.com/forum/#!forum/django-users

All the best,

  Tom

On Wednesday, 29 October 2014 16:20:02 UTC, Ronaldo Bahia wrote:
>
> *This question is also in 
> http://stackoverflow.com/questions/26635406/django-query-in-detailview
>
> I have DetailVIew wich returns a list of related objects (m2m throught). 
> It works just fine!
>
> But I need to search for objects'names and it is returning all objects 
> instead of only the related ones.
>
> How can I approach this?
>
> Thanks.
>
> #models.pyclass Candidate(models.Model):
> user = models.OneToOneField(User, primary_key=True)
> birth = models.CharField(max_length=50)
> ...
> class Job(models.Model):
> candidate = models.ManyToManyField('Candidate', through='CandidateToJob')
> title = models.CharField(max_length=500)
> ...
> class CandidateToJob(models.Model):
> job = models.ForeignKey(Job, related_name='applied_to')
> candidate = models.ForeignKey(Candidate, related_name='from_user')
> STATUS_CHOICES = (
>('1', 'Not approved'),
>('2', 'Approved'),
>('3', 'Hired')
> )
> status = models.CharField(max_length=2, choices=STATUS_CHOICES)
>
> My search query
>
>  #views.py
>  def get_query(query_string, search_fields):
> query = None # Query to search for every search term
> terms = normalize_query(query_string)
> for term in terms:
> or_query = None # Query to search for a given term in each field
> for field_name in search_fields:
> q = Q(**{"%s__icontains" % field_name: term})
> if or_query is None:
> or_query = q
> else:
> or_query = or_query | q
> if query is None:
> query = or_query
> else:
> query = query & or_query
> return query
> def searchcandidate(request, *args, **kwargs):
> query_string = ''
> found_entries = None
> if ('q' in request.GET) and request.GET['q'].strip():
> query_string = request.GET['q']
> entry_query = get_query(query_string, ['candidate__user__first_name', 
>'candidate__user__last_name'])
>
> found_entries = 
> CandidateToJob.objects.filter(entry_query).order_by('-candidate')
>
> return render_to_response('dashboard/candidates_results.html',
> { 'query_string': query_string, 'found_entries': found_entries },
> context_instance=RequestContext(request)
> )
>
> The view with the list of objects(candidates)
>
> class Screening(generic.DetailView):
>
> model = Job
> template_name = 'dashboard/screening.html'
>
> def get_context_data(self, **kwargs):
> context = super(Screening, self).get_context_data(**kwargs)
> context['candidate_list'] = 
> self.object.applied_to.all().order_by('candidate')
> return context  
>
> My urls
>
> #urls.py
> url(r'^dashboard/job/(?P\d+)/screening/$', views.Screening.as_view(), 
> name='screening'),
> url(r'^dashboard/job/(?P\d+)/screening/results/$', 
> 'companies.views.searchcandidate', name='searchcandidate'),
>
> And the templates
>
> #html for Screening(DetailView) in which works good method="get" action="{% url 'searchcandidate' job.pk %}">
> 
>  placeholder="Buscar candidatos por nome" />
> 
> 
> ...

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/02785977-14fc-403e-81d4-d784bf497147%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Websockets... again

[Collin Anderson]

Hi Luis,

There is some work on making a WSGI2 that would include support for http/2 
and likely websockets too. That would likely need to happen first or at the 
same time. https://github.com/python-web-sig/wsgi-ng

You could also check out a project called "hendrix" which supports using 
websockets with django.
https://github.com/hangarunderground/hendrix

Collin


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f61df970-139a-4497-81c9-c2f1d8ae367a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Websockets... again

[Alex Gaynor]

And after you throw away the ORM, you have to throw away every other
library that does blocking IO (anything in the stdlib, memcached, redis,
requests, etc.). There are absolutely no affordances in WSGI for use with
non-blocking libraries like asyncio or Twisted.

Alex

On Wed Oct 29 2014 at 1:45:59 AM Aymeric Augustin <
aymeric.augustin.2...@polytechnique.org> wrote:

> Then the first step is to throw away the ORM.
>
> See my talk at DjangoCon US 2013 for details.
>
> --
> Aymeric.
>
> Le 28 oct. 2014 à 23:36, Marco Paolini  a écrit :
>
> What if we do it with asyncio?
>
> 2014-10-28 22:47 GMT+01:00 Aymeric Augustin <
> aymeric.augus...@polytechnique.org>:
>
>> No, there isn’t.
>>
>> I assume that “including in core” means at least “making usable in
>> combination with WSGI and with the ORM”.
>>
>> Even if we disregard for a minute the fact that WSGI is incompatible with
>> websockets, the ORM is a hard problem, because current solutions involve
>> either (a) threads — not particularly scalable or (b) gevent — not
>> particularly reliable.
>>
>> --
>> Aymeric.
>>
>>
>>
>> On 28 oct. 2014, at 22:06, Luis Masuelli  wrote:
>>
>> Is there any current development involving including websockets in django
>> core?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/50768d16-1d05-489c-8cbf-2091d95ff388%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/7D3898D4-50F7-4ACE-A081-0ACC9D824191%40polytechnique.org
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAEbA68mnak1zdeAjTXM-Qfbz9mm%2B07qhfxZPCJPDfLFqHtcgpg%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/EEDD3BFA-B071-4FC4-93C7-0994E073D93B%40polytechnique.org
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFRnB2USMMbCp4

Re: Overwrite mode in collectstatic

[Prathik Rajendran M]

I'm happy if it is a fix for --clear either. The motivation is not "we 
messed up" but if in case someone else accidentally messed up nothing would 
happen unless they are aware of the what is going to happen, we make it 
clear that it will delete the existing files and get a prompt from them. My 
fix or patch doesn't have to be the ultimate solution but this mess did 
happen and in my opinion mess happens, the best thing we can do is prevent 
any damage happening because of it. I'm happy if any alternative solution 
comes out of it either. And who cares about what the motivation is, 
shouldn't we discuss the solution instead?

On Wednesday, October 29, 2014 9:58:51 PM UTC+5:30, Marc Tamlyn wrote:
>
> I'd be inclined to agree with Tim, this seems to simply be a less useful 
> version of --clear, for which the primary motivation was "we messed up".
> On 29 Oct 2014 16:05, "Tim Graham" > 
> wrote:
>
>> For other readers, my analysis of the issue and why I don't think it's 
>> appropriate can be found on the ticket where the idea was first raised: 
>> https://code.djangoproject.com/ticket/23724
>>
>> On Wednesday, October 29, 2014 11:34:02 AM UTC-4, Prathik Rajendran M 
>> wrote:
>>>
>>> Hi all,
>>>
>>> This is to initiate a discussion on whether we should add a new 
>>> overwrite method to collectstatic.
>>>
>>> Although I agree that we should careful in adding new features, I think 
>>> this one is pretty useful.
>>>
>>> Here is why:
>>>
>>>- We want the files in STATIC_ROOT to be replaced even if the one 
>>>there is newer. Currently I don't see a way to do this apart from using 
>>>--clear which deletes the entire directory, where other apps could be 
>>>writing too. We could implement overwrite where it does a filecmp and 
>>> then 
>>>overwrites.
>>>- The clear method deletes the files irrespective of where they are, 
>>>an accident could mean that data could be lost for ever. In one instance 
>>>our production box had STATIC_ROOT point to a folder in the app 
>>>accidentally, then collectstatic was not fetching a file from a sub app 
>>>which was linked to the main project, we ran collectstatic --clear and 
>>> it 
>>>deleted the static folder of the main project which had some base css/js 
>>>files. This could have brought down production for a while if not for a 
>>>caching mechanism.
>>>- Django should be able to run in a safe mode where no unintended 
>>>side-effects should happen.
>>>
>>> What are your thoughts on this?
>>>
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/e16d9821-95ca-43c8-930b-3e05f3a447d0%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1d7545a2-8068-44bc-b3e8-a703411deb10%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Overwrite mode in collectstatic

[Prathik Rajendran M]

And would love to hear on why you think of this as a less useful version. 
Would you suggest any changes to make it more useful? The end goal being 
that in scenarios where modified time of files in STATIC_ROOT is greater 
than that of the files in the APP, the files of the APP should replace the 
files in STATIC_ROOT without disturbing other contents in STATIC_ROOT.

Unless the design decision of Django is that files directly written to 
STATIC_ROOT shouldn't be preserved, I think overwrite is pretty useful.

An alternate solution in cases where the files in STATIC_ROOT have a 
timestamp greater that of the APP and there are files there which are used 
by other non-django APPs or there are files present there like csv 
generated by django, we go to STATIC_ROOT, manually delete the files that 
need to be replaced and run collectstatic.

On Wednesday, October 29, 2014 9:58:51 PM UTC+5:30, Marc Tamlyn wrote:
>
> I'd be inclined to agree with Tim, this seems to simply be a less useful 
> version of --clear, for which the primary motivation was "we messed up".
> On 29 Oct 2014 16:05, "Tim Graham" > 
> wrote:
>
>> For other readers, my analysis of the issue and why I don't think it's 
>> appropriate can be found on the ticket where the idea was first raised: 
>> https://code.djangoproject.com/ticket/23724
>>
>> On Wednesday, October 29, 2014 11:34:02 AM UTC-4, Prathik Rajendran M 
>> wrote:
>>>
>>> Hi all,
>>>
>>> This is to initiate a discussion on whether we should add a new 
>>> overwrite method to collectstatic.
>>>
>>> Although I agree that we should careful in adding new features, I think 
>>> this one is pretty useful.
>>>
>>> Here is why:
>>>
>>>- We want the files in STATIC_ROOT to be replaced even if the one 
>>>there is newer. Currently I don't see a way to do this apart from using 
>>>--clear which deletes the entire directory, where other apps could be 
>>>writing too. We could implement overwrite where it does a filecmp and 
>>> then 
>>>overwrites.
>>>- The clear method deletes the files irrespective of where they are, 
>>>an accident could mean that data could be lost for ever. In one instance 
>>>our production box had STATIC_ROOT point to a folder in the app 
>>>accidentally, then collectstatic was not fetching a file from a sub app 
>>>which was linked to the main project, we ran collectstatic --clear and 
>>> it 
>>>deleted the static folder of the main project which had some base css/js 
>>>files. This could have brought down production for a while if not for a 
>>>caching mechanism.
>>>- Django should be able to run in a safe mode where no unintended 
>>>side-effects should happen.
>>>
>>> What are your thoughts on this?
>>>
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/e16d9821-95ca-43c8-930b-3e05f3a447d0%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/373226bc-f46a-4b82-91e5-d70fcd6d6542%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Overwrite mode in collectstatic

[Tim Graham]

"we make it clear that it will delete the existing files and get a prompt 
from them"

Doesn't this already happen per the commits I linked in the ticket?

"Unless the design decision of Django is that files directly written to 
STATIC_ROOT shouldn't be preserved,"

Yes, as the documentation for STATIC_ROOT says, "This should be an 
(initially empty) destination directory for collecting your static files 
from their permanent locations into one directory for ease of deployment; 
it is *not* a place to store your static files permanently."

On Wednesday, October 29, 2014 12:55:29 PM UTC-4, Prathik Rajendran M wrote:
>
> And would love to hear on why you think of this as a less useful version. 
> Would you suggest any changes to make it more useful? The end goal being 
> that in scenarios where modified time of files in STATIC_ROOT is greater 
> than that of the files in the APP, the files of the APP should replace the 
> files in STATIC_ROOT without disturbing other contents in STATIC_ROOT.
>
> Unless the design decision of Django is that files directly written to 
> STATIC_ROOT shouldn't be preserved, I think overwrite is pretty useful.
>
> An alternate solution in cases where the files in STATIC_ROOT have a 
> timestamp greater that of the APP and there are files there which are used 
> by other non-django APPs or there are files present there like csv 
> generated by django, we go to STATIC_ROOT, manually delete the files that 
> need to be replaced and run collectstatic.
>
> On Wednesday, October 29, 2014 9:58:51 PM UTC+5:30, Marc Tamlyn wrote:
>>
>> I'd be inclined to agree with Tim, this seems to simply be a less useful 
>> version of --clear, for which the primary motivation was "we messed up".
>> On 29 Oct 2014 16:05, "Tim Graham"  wrote:
>>
>>> For other readers, my analysis of the issue and why I don't think it's 
>>> appropriate can be found on the ticket where the idea was first raised: 
>>> https://code.djangoproject.com/ticket/23724
>>>
>>> On Wednesday, October 29, 2014 11:34:02 AM UTC-4, Prathik Rajendran M 
>>> wrote:

 Hi all,

 This is to initiate a discussion on whether we should add a new 
 overwrite method to collectstatic.

 Although I agree that we should careful in adding new features, I think 
 this one is pretty useful.

 Here is why:

- We want the files in STATIC_ROOT to be replaced even if the one 
there is newer. Currently I don't see a way to do this apart from using 
--clear which deletes the entire directory, where other apps could be 
writing too. We could implement overwrite where it does a filecmp and 
 then 
overwrites.
- The clear method deletes the files irrespective of where they 
are, an accident could mean that data could be lost for ever. In one 
instance our production box had STATIC_ROOT point to a folder in the 
 app 
accidentally, then collectstatic was not fetching a file from a sub app 
which was linked to the main project, we ran collectstatic --clear and 
 it 
deleted the static folder of the main project which had some base 
 css/js 
files. This could have brought down production for a while if not for a 
caching mechanism.
- Django should be able to run in a safe mode where no unintended 
side-effects should happen.

 What are your thoughts on this?

>>>  -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to django-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/e16d9821-95ca-43c8-930b-3e05f3a447d0%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/530b911a-ba66-49b1-9dc4-8260a46e5f91%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Overwrite mode in collectstatic

[Prathik Rajendran M]

Hi Tim,

Doesn't this already happen per the commits I linked in the ticket?


As far as I can see it tells that the existing files will be deleted, which 
is true, but it doesn't tell that the files of the STATIC_ROOT are same as 
the APP (in the scenario I mentioned) and that it can't be restored. It 
should tell this in order to mitigate unknown damage. This can be inferred 
from the location of the STATIC_ROOT if it is printed while clear is being 
done but it is possible that the person who is running the clear command 
missed this.

Yes, as the documentation for STATIC_ROOT says, "This should be an 
> (initially empty) destination directory for collecting your static files 
> from their permanent locations into one directory for ease of deployment; 
> it is *not* a place to store your static files permanently."


This makes it necessary that a STATIC_ROOT location is fixed for Django 
itself but it then adds a friction for other apps running with it. We 
should minimize the requirement that people learn certain laws before using 
Django because it is possible that they don't and ideally we should have 
mechanisms to figure out that they are not and then alert them, I am not 
sure if these alerts are there.

Thanks,
Prathik

On Wednesday, October 29, 2014 10:51:13 PM UTC+5:30, Tim Graham wrote:
>
> "we make it clear that it will delete the existing files and get a prompt 
> from them"
>
> Doesn't this already happen per the commits I linked in the ticket?
>
> "Unless the design decision of Django is that files directly written to 
> STATIC_ROOT shouldn't be preserved,"
>
> Yes, as the documentation for STATIC_ROOT says, "This should be an 
> (initially empty) destination directory for collecting your static files 
> from their permanent locations into one directory for ease of deployment; 
> it is *not* a place to store your static files permanently."
>
> On Wednesday, October 29, 2014 12:55:29 PM UTC-4, Prathik Rajendran M 
> wrote:
>>
>> And would love to hear on why you think of this as a less useful version. 
>> Would you suggest any changes to make it more useful? The end goal being 
>> that in scenarios where modified time of files in STATIC_ROOT is greater 
>> than that of the files in the APP, the files of the APP should replace the 
>> files in STATIC_ROOT without disturbing other contents in STATIC_ROOT.
>>
>> Unless the design decision of Django is that files directly written to 
>> STATIC_ROOT shouldn't be preserved, I think overwrite is pretty useful.
>>
>> An alternate solution in cases where the files in STATIC_ROOT have a 
>> timestamp greater that of the APP and there are files there which are used 
>> by other non-django APPs or there are files present there like csv 
>> generated by django, we go to STATIC_ROOT, manually delete the files that 
>> need to be replaced and run collectstatic.
>>
>> On Wednesday, October 29, 2014 9:58:51 PM UTC+5:30, Marc Tamlyn wrote:
>>>
>>> I'd be inclined to agree with Tim, this seems to simply be a less useful 
>>> version of --clear, for which the primary motivation was "we messed up".
>>> On 29 Oct 2014 16:05, "Tim Graham"  wrote:
>>>
 For other readers, my analysis of the issue and why I don't think it's 
 appropriate can be found on the ticket where the idea was first raised: 
 https://code.djangoproject.com/ticket/23724

 On Wednesday, October 29, 2014 11:34:02 AM UTC-4, Prathik Rajendran M 
 wrote:
>
> Hi all,
>
> This is to initiate a discussion on whether we should add a new 
> overwrite method to collectstatic.
>
> Although I agree that we should careful in adding new features, I 
> think this one is pretty useful.
>
> Here is why:
>
>- We want the files in STATIC_ROOT to be replaced even if the one 
>there is newer. Currently I don't see a way to do this apart from 
> using 
>--clear which deletes the entire directory, where other apps could be 
>writing too. We could implement overwrite where it does a filecmp and 
> then 
>overwrites.
>- The clear method deletes the files irrespective of where they 
>are, an accident could mean that data could be lost for ever. In one 
>instance our production box had STATIC_ROOT point to a folder in the 
> app 
>accidentally, then collectstatic was not fetching a file from a sub 
> app 
>which was linked to the main project, we ran collectstatic --clear and 
> it 
>deleted the static folder of the main project which had some base 
> css/js 
>files. This could have brought down production for a while if not for 
> a 
>caching mechanism.
>- Django should be able to run in a safe mode where no unintended 
>side-effects should happen.
>
> What are your thoughts on this?
>
  -- 
 You received this message because you are subscribed to the Google 
 Groups "Django developers

Re: Overwrite mode in collectstatic

[Tim Graham]

I just don't see the value here. A problem happens if a user:

1) doesn't read the docs for STATIC_ROOT and sets it incorrectly AND
2) doesn't understand the following prompt:

You have requested to collect static files at the destination
location as specified in your settings:

/home/tim/code/mysite/static

This will DELETE ALL FILES in this location!
Are you sure you want to do this?

Type 'yes' to continue, or 'no' to cancel:

Maybe we can tweak the message if it's not clear, but adding more code 
logic to try to make the error message "smarter" seems overkill to me.

On Wednesday, October 29, 2014 1:41:56 PM UTC-4, Prathik Rajendran M wrote:
>
> Hi Tim,
>
> Doesn't this already happen per the commits I linked in the ticket?
>
>
> As far as I can see it tells that the existing files will be deleted, 
> which is true, but it doesn't tell that the files of the STATIC_ROOT are 
> same as the APP (in the scenario I mentioned) and that it can't be 
> restored. It should tell this in order to mitigate unknown damage. This can 
> be inferred from the location of the STATIC_ROOT if it is printed while 
> clear is being done but it is possible that the person who is running the 
> clear command missed this.
>
> Yes, as the documentation for STATIC_ROOT says, "This should be an 
>> (initially empty) destination directory for collecting your static files 
>> from their permanent locations into one directory for ease of deployment; 
>> it is *not* a place to store your static files permanently."
>
>
> This makes it necessary that a STATIC_ROOT location is fixed for Django 
> itself but it then adds a friction for other apps running with it. We 
> should minimize the requirement that people learn certain laws before using 
> Django because it is possible that they don't and ideally we should have 
> mechanisms to figure out that they are not and then alert them, I am not 
> sure if these alerts are there.
>
> Thanks,
> Prathik
>
> On Wednesday, October 29, 2014 10:51:13 PM UTC+5:30, Tim Graham wrote:
>>
>> "we make it clear that it will delete the existing files and get a prompt 
>> from them"
>>
>> Doesn't this already happen per the commits I linked in the ticket?
>>
>> "Unless the design decision of Django is that files directly written to 
>> STATIC_ROOT shouldn't be preserved,"
>>
>> Yes, as the documentation for STATIC_ROOT says, "This should be an 
>> (initially empty) destination directory for collecting your static files 
>> from their permanent locations into one directory for ease of deployment; 
>> it is *not* a place to store your static files permanently."
>>
>> On Wednesday, October 29, 2014 12:55:29 PM UTC-4, Prathik Rajendran M 
>> wrote:
>>>
>>> And would love to hear on why you think of this as a less useful 
>>> version. Would you suggest any changes to make it more useful? The end goal 
>>> being that in scenarios where modified time of files in STATIC_ROOT is 
>>> greater than that of the files in the APP, the files of the APP should 
>>> replace the files in STATIC_ROOT without disturbing other contents in 
>>> STATIC_ROOT.
>>>
>>> Unless the design decision of Django is that files directly written to 
>>> STATIC_ROOT shouldn't be preserved, I think overwrite is pretty useful.
>>>
>>> An alternate solution in cases where the files in STATIC_ROOT have a 
>>> timestamp greater that of the APP and there are files there which are used 
>>> by other non-django APPs or there are files present there like csv 
>>> generated by django, we go to STATIC_ROOT, manually delete the files that 
>>> need to be replaced and run collectstatic.
>>>
>>> On Wednesday, October 29, 2014 9:58:51 PM UTC+5:30, Marc Tamlyn wrote:

 I'd be inclined to agree with Tim, this seems to simply be a less 
 useful version of --clear, for which the primary motivation was "we messed 
 up".
 On 29 Oct 2014 16:05, "Tim Graham"  wrote:

> For other readers, my analysis of the issue and why I don't think it's 
> appropriate can be found on the ticket where the idea was first raised: 
> https://code.djangoproject.com/ticket/23724
>
> On Wednesday, October 29, 2014 11:34:02 AM UTC-4, Prathik Rajendran M 
> wrote:
>>
>> Hi all,
>>
>> This is to initiate a discussion on whether we should add a new 
>> overwrite method to collectstatic.
>>
>> Although I agree that we should careful in adding new features, I 
>> think this one is pretty useful.
>>
>> Here is why:
>>
>>- We want the files in STATIC_ROOT to be replaced even if the one 
>>there is newer. Currently I don't see a way to do this apart from 
>> using 
>>--clear which deletes the entire directory, where other apps could be 
>>writing too. We could implement overwrite where it does a filecmp and 
>> then 
>>overwrites.
>>- The clear method deletes the files irrespective of where they 
>>are, an accident could mean that data c

Re: Overwrite mode in collectstatic

[Shai Berger]

I agree with Tim completely.

I do see one thing that could help here: Add a check that STATIC_ROOT is not a 
subfolder of any app. This check cannot be really reliable (that is, a 
particularly careless and unlucky user could set things up so that their 
STATIC_ROOT is in an app but the check will not notice it -- a couple of soft-
links will do the trick), but a blunder as described here (STATIC_ROOT is 
simply the same as the static folder of an app) can be identified and warned 
against.

I don't think such a check belongs in Django, given its inherent unreliability 
and the low probabiity of such errors (this is the first time I've heard of 
one), but with 1.7, you could just add it yourself; you can publish it and it 
can live as a 3rd-party library until it proves me wrong by gaining wide-
spread use.

Shai. 

On Wednesday 29 October 2014 20:12:21 Tim Graham wrote:
> I just don't see the value here. A problem happens if a user:
> 
> 1) doesn't read the docs for STATIC_ROOT and sets it incorrectly AND
> 2) doesn't understand the following prompt:
> 
> You have requested to collect static files at the destination
> location as specified in your settings:
> 
> /home/tim/code/mysite/static
> 
> This will DELETE ALL FILES in this location!
> Are you sure you want to do this?
> 
> Type 'yes' to continue, or 'no' to cancel:
> 
> Maybe we can tweak the message if it's not clear, but adding more code
> logic to try to make the error message "smarter" seems overkill to me.
> 
> On Wednesday, October 29, 2014 1:41:56 PM UTC-4, Prathik Rajendran M wrote:
> > Hi Tim,
> > 
> > Doesn't this already happen per the commits I linked in the ticket?
> > 
> > 
> > As far as I can see it tells that the existing files will be deleted,
> > which is true, but it doesn't tell that the files of the STATIC_ROOT are
> > same as the APP (in the scenario I mentioned) and that it can't be
> > restored. It should tell this in order to mitigate unknown damage. This
> > can be inferred from the location of the STATIC_ROOT if it is printed
> > while clear is being done but it is possible that the person who is
> > running the clear command missed this.
> > 
> > Yes, as the documentation for STATIC_ROOT says, "This should be an
> > 
> >> (initially empty) destination directory for collecting your static files
> >> from their permanent locations into one directory for ease of
> >> deployment; it is *not* a place to store your static files
> >> permanently."
> > 
> > This makes it necessary that a STATIC_ROOT location is fixed for Django
> > itself but it then adds a friction for other apps running with it. We
> > should minimize the requirement that people learn certain laws before
> > using Django because it is possible that they don't and ideally we
> > should have mechanisms to figure out that they are not and then alert
> > them, I am not sure if these alerts are there.
> > 
> > Thanks,
> > Prathik
> > 
> > On Wednesday, October 29, 2014 10:51:13 PM UTC+5:30, Tim Graham wrote:
> >> "we make it clear that it will delete the existing files and get a
> >> prompt from them"
> >> 
> >> Doesn't this already happen per the commits I linked in the ticket?
> >> 
> >> "Unless the design decision of Django is that files directly written to
> >> STATIC_ROOT shouldn't be preserved,"
> >> 
> >> Yes, as the documentation for STATIC_ROOT says, "This should be an
> >> (initially empty) destination directory for collecting your static files
> >> from their permanent locations into one directory for ease of
> >> deployment; it is *not* a place to store your static files
> >> permanently."
> >> 
> >> On Wednesday, October 29, 2014 12:55:29 PM UTC-4, Prathik Rajendran M
> >> 
> >> wrote:
> >>> And would love to hear on why you think of this as a less useful
> >>> version. Would you suggest any changes to make it more useful? The end
> >>> goal being that in scenarios where modified time of files in
> >>> STATIC_ROOT is greater than that of the files in the APP, the files of
> >>> the APP should replace the files in STATIC_ROOT without disturbing
> >>> other contents in STATIC_ROOT.
> >>> 
> >>> Unless the design decision of Django is that files directly written to
> >>> STATIC_ROOT shouldn't be preserved, I think overwrite is pretty useful.
> >>> 
> >>> An alternate solution in cases where the files in STATIC_ROOT have a
> >>> timestamp greater that of the APP and there are files there which are
> >>> used by other non-django APPs or there are files present there like
> >>> csv generated by django, we go to STATIC_ROOT, manually delete the
> >>> files that need to be replaced and run collectstatic.
> >>> 
> >>> On Wednesday, October 29, 2014 9:58:51 PM UTC+5:30, Marc Tamlyn wrote:
>  I'd be inclined to agree with Tim, this seems to simply be a less
>  useful version of --clear, for which the primary motivation was "we
>  messed up".
>  
>  On 29 Oct 2014 16:05, "Tim Graham"  wrote:
> > For other readers, my analysis of the is

Re: sys.exit(1) from makemigrations if no changes found

[Tim Heap]

The backwards compatibility issue I was thinking of is for people using 
`makemigrations` in a script currently, expecting it to exit with 0 unless 
something very wrong has happened. For example, if `makemigrations` is run 
in a bash script with `set -e`, and it does not find any migrations, that 
script will then exit. Alternately, if someone is using a one-liner like 
`./manage.py makemigrations && ./manage.py migrate && another command` the 
makemigrations command will cause the whole command to abort early, even 
though no 'error' as such has happened. Backwards compatibility aside, this 
would be awkward to work around in scripts without simply ignoring the exit 
code of `makemigrations` completely, which then ignores legitimate errors.

I have made a patch that calls `sys.exit(1)` when no changes are found, and 
made a pull request at https://github.com/django/django/pull/3441

Tim

On Wednesday, October 29, 2014 1:04:31 PM UTC+11, Andrew Godwin wrote:
>
> I'm actually fine with option 1 - always exiting with a status code if no 
> migrations are found. Since the status code does nothing useful at the 
> moment, I don't see any backwards compatibility issues, and as long as it's 
> a suitably small patch, it should be fine.
>
> (As for being surprising compared to grep, there are many other commands 
> with different exit codes one could draw parallels to; I'm not sure being 
> consistent with a very different utility is a worthwhile cause).
>
> Andrew
>
> On Tue, Oct 28, 2014 at 6:22 PM, Tim Heap > 
> wrote:
>
>> Hi all,
>>
>> I have created a ticket for this (
>> https://code.djangoproject.com/ticket/23728) but I would like some input 
>> before I work on it. I will copy the content of the ticket below for ease 
>> of reading:
>>
>> It would be very useful for continuous deployment, testing, commit hooks, 
>> and other applications if django-admin makemigrations signaled via an 
>> exit code if any migrations were found. Commits in projects could be 
>> rejected if migrations were outstanding, continuous deployment systems 
>> could fail the build on outstanding migrations, and potentially other uses. 
>> No more would hasty commits break things when developers forgot to make 
>> migrations!
>>
>> Changes to the code to make this happen are easy enough, but I am unsure 
>> how the command should behave. The grep unix utility is a example to 
>> copy. Under normal operation, grep always exits 0 unless an error 
>> happens, regardless of whether it found any matches. Invoking grep with 
>> the -q/--quiet flag causes grep to be silent, not printing anything, as 
>> well as exiting 0 if matches are found and 1 if nothing is found.
>>
>> I am proposing django-admin makemigrations should exit with 1 (or 
>> anything non-zero) if no migrations to make were found, or exit 0 if 
>> migrations to make were found. As the command is instructed to make 
>> migrations, not making any is the error case.
>>
>> I am unsure how this new functionality should be selected by the user 
>> when invoking makemigrations. The options I see are:
>>
>>1. Enable this always. This is very simple to implement and easy to 
>>understand. Good unixy tools use error codes extensively to signal 
>> errors. 
>>This may be surprising behaviour when compared to grep though, and breaks 
>>backwards compatibility in a minor way.
>>2. Enable this when the --dry-run flag is enabled. Now this flag can 
>>be used to check for migrations that need to be created both visually via 
>>the printed text, and composed in shell commands.
>>3. Add a new flag -e/--exit (or similar). The sole purpose of this 
>>flag would be to exit with 1 when no migrations were found. This could be 
>>combined with --dry-run to just check for migrations that need to be 
>>made.
>>4. Add a new flag -q/--quiet that copies the behaviour of greps 
>>-q/--quiet flag: silences output and exits with 1 when no migrations 
>>were found. This duplicates functionality though, as logging can be 
>>silenced using -v0 already.
>>
>> My personal preference is for option 2. I was surprised when enabling 
>> --dry-run did not signal its result via the exit code. 3 would be the 
>> cleanest and most composable option, as 4 could be emulated using -ev0.
>>
>> I will implement this change using 2, unless other people have opinions 
>> on the matter.
>>
>> Regards,
>> Tim
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/92203dcb-a775-4c17-a831-97d01ce8af3c%

Re: sys.exit(1) from makemigrations if no changes found

[Markus Holtermann]

I like the general idea, but I slightly disagree with "As the command is 
instructed to make migrations, not making any is the error case.". Yes, 
grep works that way but I thing this are two different use cases. I think 
makemigrations on a project without any changes in the models' database 
representation shouldn't exit with RC>0. I'd prefer to have the return code 
either only set on dry-run or explicitly when using -e/--exit. I'm in favor 
of 2. or 3.

/Markus

On Wednesday, October 29, 2014 8:44:31 AM UTC+1, Marc Tamlyn wrote:
>
> I agree number 1 is fine. For most general interaction with the command 
> users won't notice.
>
> Marc
> On 29 Oct 2014 02:04, "Andrew Godwin" > 
> wrote:
>
>> I'm actually fine with option 1 - always exiting with a status code if no 
>> migrations are found. Since the status code does nothing useful at the 
>> moment, I don't see any backwards compatibility issues, and as long as it's 
>> a suitably small patch, it should be fine.
>>
>> (As for being surprising compared to grep, there are many other commands 
>> with different exit codes one could draw parallels to; I'm not sure being 
>> consistent with a very different utility is a worthwhile cause).
>>
>> Andrew
>>
>> On Tue, Oct 28, 2014 at 6:22 PM, Tim Heap > 
>> wrote:
>>
>>> Hi all,
>>>
>>> I have created a ticket for this (
>>> https://code.djangoproject.com/ticket/23728) but I would like some 
>>> input before I work on it. I will copy the content of the ticket below for 
>>> ease of reading:
>>>
>>> It would be very useful for continuous deployment, testing, commit 
>>> hooks, and other applications if django-admin makemigrations signaled 
>>> via an exit code if any migrations were found. Commits in projects could be 
>>> rejected if migrations were outstanding, continuous deployment systems 
>>> could fail the build on outstanding migrations, and potentially other uses. 
>>> No more would hasty commits break things when developers forgot to make 
>>> migrations!
>>>
>>> Changes to the code to make this happen are easy enough, but I am unsure 
>>> how the command should behave. The grep unix utility is a example to 
>>> copy. Under normal operation, grep always exits 0 unless an error 
>>> happens, regardless of whether it found any matches. Invoking grep with 
>>> the -q/--quiet flag causes grep to be silent, not printing anything, as 
>>> well as exiting 0 if matches are found and 1 if nothing is found.
>>>
>>> I am proposing django-admin makemigrations should exit with 1 (or 
>>> anything non-zero) if no migrations to make were found, or exit 0 if 
>>> migrations to make were found. As the command is instructed to make 
>>> migrations, not making any is the error case.
>>>
>>> I am unsure how this new functionality should be selected by the user 
>>> when invoking makemigrations. The options I see are:
>>>
>>>1. Enable this always. This is very simple to implement and easy to 
>>>understand. Good unixy tools use error codes extensively to signal 
>>> errors. 
>>>This may be surprising behaviour when compared to grep though, and 
>>> breaks 
>>>backwards compatibility in a minor way.
>>>2. Enable this when the --dry-run flag is enabled. Now this flag can 
>>>be used to check for migrations that need to be created both visually 
>>> via 
>>>the printed text, and composed in shell commands.
>>>3. Add a new flag -e/--exit (or similar). The sole purpose of this 
>>>flag would be to exit with 1 when no migrations were found. This could 
>>> be 
>>>combined with --dry-run to just check for migrations that need to be 
>>>made.
>>>4. Add a new flag -q/--quiet that copies the behaviour of greps 
>>>-q/--quiet flag: silences output and exits with 1 when no migrations 
>>>were found. This duplicates functionality though, as logging can be 
>>>silenced using -v0 already.
>>>
>>> My personal preference is for option 2. I was surprised when enabling 
>>> --dry-run did not signal its result via the exit code. 3 would be the 
>>> cleanest and most composable option, as 4 could be emulated using -ev0.
>>>
>>> I will implement this change using 2, unless other people have opinions 
>>> on the matter.
>>>
>>> Regards,
>>> Tim
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to django-develop...@googlegroups.com .
>>> To post to this group, send email to django-d...@googlegroups.com 
>>> .
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/92203dcb-a775-4c17-a831-97d01ce8af3c%40googlegroups.com
>>>  
>>> 
>>> .

Add ability to show the migration plan (#23359)

[Markus Holtermann]

Hey folks,

A few weeks ago I opened a ticket 
(https://code.djangoproject.com/ticket/23359) to add the ability to show a 
migration plan similar as listing all migrations within a project 
(manage.py migrate --list). After some discussions on IRC and on the first 
pull request (https://github.com/django/django/pull/3116) we realized that 
there might even be more use cases, e.g. to output all migration files as a 
dot file to generate a graph 
(https://github.com/django/django/pull/3116#issuecomment-53565075). That's 
when I opened a second pull request that moves the existing "--list" and 
the new "--plan" option from the "migrate" command to a "showmigrations" 
command.

Any suggestions on which way I should follow, integrate in "manage.py 
migrate" (pull request 3116: https://github.com/django/django/pull/3116) or 
add a new dedicated command "manage.py showmigrations" (pull request 3153: 
https://github.com/django/django/pull/3153)?

/Markus

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f8bdabfc-f005-4e8e-b1d9-0b69dfdedd82%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: sys.exit(1) from makemigrations if no changes found

[Tim Heap]

I also agree that users should opt-in to enabling the error, using option 2 
or 3, but I will implement what ever the popular option is.

My argument regarding "As the command is instructed to make migrations, not 
making any is the error case." was more about when to return the error: 
either when changes *are* found, or when changes are *not* found. As the 
command is attempting to make a migration, not finding any changes is the 
exceptional case, and should return an error code (if enabled via flags, or 
however it will eventually work).

On Thursday, October 30, 2014 10:30:50 AM UTC+11, Markus Holtermann wrote:
>
> I like the general idea, but I slightly disagree with "As the command is 
> instructed to make migrations, not making any is the error case.". Yes, 
> grep works that way but I thing this are two different use cases. I think 
> makemigrations on a project without any changes in the models' database 
> representation shouldn't exit with RC>0. I'd prefer to have the return code 
> either only set on dry-run or explicitly when using -e/--exit. I'm in favor 
> of 2. or 3.
>
> /Markus
>
> On Wednesday, October 29, 2014 8:44:31 AM UTC+1, Marc Tamlyn wrote:
>>
>> I agree number 1 is fine. For most general interaction with the command 
>> users won't notice.
>>
>> Marc
>> On 29 Oct 2014 02:04, "Andrew Godwin"  wrote:
>>
>>> I'm actually fine with option 1 - always exiting with a status code if 
>>> no migrations are found. Since the status code does nothing useful at the 
>>> moment, I don't see any backwards compatibility issues, and as long as it's 
>>> a suitably small patch, it should be fine.
>>>
>>> (As for being surprising compared to grep, there are many other commands 
>>> with different exit codes one could draw parallels to; I'm not sure being 
>>> consistent with a very different utility is a worthwhile cause).
>>>
>>> Andrew
>>>
>>> On Tue, Oct 28, 2014 at 6:22 PM, Tim Heap  wrote:
>>>
 Hi all,

 I have created a ticket for this (
 https://code.djangoproject.com/ticket/23728) but I would like some 
 input before I work on it. I will copy the content of the ticket below for 
 ease of reading:

 It would be very useful for continuous deployment, testing, commit 
 hooks, and other applications if django-admin makemigrations signaled 
 via an exit code if any migrations were found. Commits in projects could 
 be 
 rejected if migrations were outstanding, continuous deployment systems 
 could fail the build on outstanding migrations, and potentially other 
 uses. 
 No more would hasty commits break things when developers forgot to make 
 migrations!

 Changes to the code to make this happen are easy enough, but I am 
 unsure how the command should behave. The grep unix utility is a 
 example to copy. Under normal operation, grep always exits 0 unless an 
 error happens, regardless of whether it found any matches. Invoking 
 grep with the -q/--quiet flag causes grep to be silent, not printing 
 anything, as well as exiting 0 if matches are found and 1 if nothing is 
 found.

 I am proposing django-admin makemigrations should exit with 1 (or 
 anything non-zero) if no migrations to make were found, or exit 0 if 
 migrations to make were found. As the command is instructed to make 
 migrations, not making any is the error case.

 I am unsure how this new functionality should be selected by the user 
 when invoking makemigrations. The options I see are:

1. Enable this always. This is very simple to implement and easy to 
understand. Good unixy tools use error codes extensively to signal 
 errors. 
This may be surprising behaviour when compared to grep though, and 
 breaks 
backwards compatibility in a minor way.
2. Enable this when the --dry-run flag is enabled. Now this flag 
can be used to check for migrations that need to be created both 
 visually 
via the printed text, and composed in shell commands.
3. Add a new flag -e/--exit (or similar). The sole purpose of this 
flag would be to exit with 1 when no migrations were found. This could 
 be 
combined with --dry-run to just check for migrations that need to 
be made.
4. Add a new flag -q/--quiet that copies the behaviour of greps 
-q/--quiet flag: silences output and exits with 1 when no 
migrations were found. This duplicates functionality though, as logging 
 can 
be silenced using -v0 already.

 My personal preference is for option 2. I was surprised when enabling 
 --dry-run did not signal its result via the exit code. 3 would be the 
 cleanest and most composable option, as 4 could be emulated using -ev0.

 I will implement this change using 2, unless other people have opinions 
 on the matter.

 Regards,
 Tim

 -- 

Re: sys.exit(1) from makemigrations if no changes found

[Daryl]

I'm +1 on being able to continue using the line
./manage.py makemigrations && ./manage.py migrate

I can't see many (any?) situation where someone *wouldn't* run
makemigrations & migrate as one logical operation, whether by typing
the commands or running a script.
What would the workflow be where you would make migrations but not apply them?

D



On 30 October 2014 12:29, Tim Heap  wrote:
> The backwards compatibility issue I was thinking of is for people using
> `makemigrations` in a script currently, expecting it to exit with 0 unless
> something very wrong has happened. For example, if `makemigrations` is run
> in a bash script with `set -e`, and it does not find any migrations, that
> script will then exit. Alternately, if someone is using a one-liner like
> `./manage.py makemigrations && ./manage.py migrate && another command` the
> makemigrations command will cause the whole command to abort early, even
> though no 'error' as such has happened. Backwards compatibility aside, this
> would be awkward to work around in scripts without simply ignoring the exit
> code of `makemigrations` completely, which then ignores legitimate errors.
>
> I have made a patch that calls `sys.exit(1)` when no changes are found, and
> made a pull request at https://github.com/django/django/pull/3441
>
> Tim
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALzH9qsJ-qgPxGzmeMF3Lt9oXsn-eRk%3DUSNS%2BxZmbaKinMA2ww%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add ability to show the migration plan (#23359)

[Andrew Godwin]

This used to be called "graphmigrations" in South, so I'm +0 on moving it
to showmigrations; I don't want migrate to gain any extra functionality.
That said, I tried moving --list to something separate during the 1.7 phase
but there were objections to people who liked it on migrate.

I don't really mind which way you go, to be honest; both seem like sensible
places. Other people might have stronger opinions.

Andrew

On Wed, Oct 29, 2014 at 4:44 PM, Markus Holtermann  wrote:

> Hey folks,
>
> A few weeks ago I opened a ticket (
> https://code.djangoproject.com/ticket/23359) to add the ability to show a
> migration plan similar as listing all migrations within a project
> (manage.py migrate --list). After some discussions on IRC and on the first
> pull request (https://github.com/django/django/pull/3116) we realized
> that there might even be more use cases, e.g. to output all migration files
> as a dot file to generate a graph (
> https://github.com/django/django/pull/3116#issuecomment-53565075). That's
> when I opened a second pull request that moves the existing "--list" and
> the new "--plan" option from the "migrate" command to a "showmigrations"
> command.
>
> Any suggestions on which way I should follow, integrate in "manage.py
> migrate" (pull request 3116: https://github.com/django/django/pull/3116)
> or add a new dedicated command "manage.py showmigrations" (pull request
> 3153: https://github.com/django/django/pull/3153)?
>
> /Markus
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/f8bdabfc-f005-4e8e-b1d9-0b69dfdedd82%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFwN1urG_CG71CYQFwymvK3MKMGJMoMtfiA7wze2gHwnXMbd3g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: sys.exit(1) from makemigrations if no changes found

[Tim Heap]

If makemigrations exits with something other than 0, it will not have 
created any migrations to run anyway, so running the makemigrations & 
migrate pair here would not be affected. However, a useful one liner that I 
have been using when developing is:

./manage.py makemigrations && ./manage.py migrate && ./manage.py runserver

If the exit code was always used, chains like this would become much more 
awkward to use, which is why my preference is for option 2 or 3.

Making migrations and not applying them is useful if you want to review or 
edit the migrations before applying them - perhaps to split the migration 
in to two logical chunks for two different commits, or to append some 
manual migration code to the automatically generated migration. As part of 
continuous integration I also want to run:

./manage.py makemigrations --dry-run --exit || fail-build "Outstanding 
database changes with no migrations"

This way, the build fails if there are outstanding migrations. I am not 
interested in creating or running migrations in this instance, just 
checking that everything is up to date.

On Thursday, October 30, 2014 12:21:11 PM UTC+11, Daryl wrote:
>
> I'm +1 on being able to continue using the line 
> ./manage.py makemigrations && ./manage.py migrate 
>
> I can't see many (any?) situation where someone *wouldn't* run 
> makemigrations & migrate as one logical operation, whether by typing 
> the commands or running a script. 
> What would the workflow be where you would make migrations but not apply 
> them? 
>
> D 
>
>
>
> On 30 October 2014 12:29, Tim Heap > wrote: 
> > The backwards compatibility issue I was thinking of is for people using 
> > `makemigrations` in a script currently, expecting it to exit with 0 
> unless 
> > something very wrong has happened. For example, if `makemigrations` is 
> run 
> > in a bash script with `set -e`, and it does not find any migrations, 
> that 
> > script will then exit. Alternately, if someone is using a one-liner like 
> > `./manage.py makemigrations && ./manage.py migrate && another command` 
> the 
> > makemigrations command will cause the whole command to abort early, even 
> > though no 'error' as such has happened. Backwards compatibility aside, 
> this 
> > would be awkward to work around in scripts without simply ignoring the 
> exit 
> > code of `makemigrations` completely, which then ignores legitimate 
> errors. 
> > 
> > I have made a patch that calls `sys.exit(1)` when no changes are found, 
> and 
> > made a pull request at https://github.com/django/django/pull/3441 
> > 
> > Tim 
> > 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/102bf2cd-f843-4dac-9374-6d1f5d20c59f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Overwrite mode in collectstatic

[Prathik Rajendran M]

Let's say you run --clear often and in most cases it won't cause a problem 
and the same message is shown, let's say someone else in your team set the 
STATIC_FOLDER to a file in the app, in this case wouldn't you want an 
explicit message that unlike in the previous scenarios where STATIC_FOLDER 
is separate, in this scenario the files deleted cannot be brought back? I 
think this would make django safer.

Shai, overwrite is just a proposal, I basically wanted a way in which even 
if the files in STATIC_ROOT were newer they'd get replaced without having 
to delete all the files.

On Wednesday, October 29, 2014 11:42:21 PM UTC+5:30, Tim Graham wrote:
>
> I just don't see the value here. A problem happens if a user:
>
> 1) doesn't read the docs for STATIC_ROOT and sets it incorrectly AND
> 2) doesn't understand the following prompt:
>
> You have requested to collect static files at the destination
> location as specified in your settings:
>
> /home/tim/code/mysite/static
>
> This will DELETE ALL FILES in this location!
> Are you sure you want to do this?
>
> Type 'yes' to continue, or 'no' to cancel:
>
> Maybe we can tweak the message if it's not clear, but adding more code 
> logic to try to make the error message "smarter" seems overkill to me.
>
> On Wednesday, October 29, 2014 1:41:56 PM UTC-4, Prathik Rajendran M wrote:
>>
>> Hi Tim,
>>
>> Doesn't this already happen per the commits I linked in the ticket?
>>
>>
>> As far as I can see it tells that the existing files will be deleted, 
>> which is true, but it doesn't tell that the files of the STATIC_ROOT are 
>> same as the APP (in the scenario I mentioned) and that it can't be 
>> restored. It should tell this in order to mitigate unknown damage. This can 
>> be inferred from the location of the STATIC_ROOT if it is printed while 
>> clear is being done but it is possible that the person who is running the 
>> clear command missed this.
>>
>> Yes, as the documentation for STATIC_ROOT says, "This should be an 
>>> (initially empty) destination directory for collecting your static files 
>>> from their permanent locations into one directory for ease of deployment; 
>>> it is *not* a place to store your static files permanently."
>>
>>
>> This makes it necessary that a STATIC_ROOT location is fixed for Django 
>> itself but it then adds a friction for other apps running with it. We 
>> should minimize the requirement that people learn certain laws before using 
>> Django because it is possible that they don't and ideally we should have 
>> mechanisms to figure out that they are not and then alert them, I am not 
>> sure if these alerts are there.
>>
>> Thanks,
>> Prathik
>>
>> On Wednesday, October 29, 2014 10:51:13 PM UTC+5:30, Tim Graham wrote:
>>>
>>> "we make it clear that it will delete the existing files and get a 
>>> prompt from them"
>>>
>>> Doesn't this already happen per the commits I linked in the ticket?
>>>
>>> "Unless the design decision of Django is that files directly written to 
>>> STATIC_ROOT shouldn't be preserved,"
>>>
>>> Yes, as the documentation for STATIC_ROOT says, "This should be an 
>>> (initially empty) destination directory for collecting your static files 
>>> from their permanent locations into one directory for ease of deployment; 
>>> it is *not* a place to store your static files permanently."
>>>
>>> On Wednesday, October 29, 2014 12:55:29 PM UTC-4, Prathik Rajendran M 
>>> wrote:

 And would love to hear on why you think of this as a less useful 
 version. Would you suggest any changes to make it more useful? The end 
 goal 
 being that in scenarios where modified time of files in STATIC_ROOT is 
 greater than that of the files in the APP, the files of the APP should 
 replace the files in STATIC_ROOT without disturbing other contents in 
 STATIC_ROOT.

 Unless the design decision of Django is that files directly written to 
 STATIC_ROOT shouldn't be preserved, I think overwrite is pretty useful.

 An alternate solution in cases where the files in STATIC_ROOT have a 
 timestamp greater that of the APP and there are files there which are used 
 by other non-django APPs or there are files present there like csv 
 generated by django, we go to STATIC_ROOT, manually delete the files that 
 need to be replaced and run collectstatic.

 On Wednesday, October 29, 2014 9:58:51 PM UTC+5:30, Marc Tamlyn wrote:
>
> I'd be inclined to agree with Tim, this seems to simply be a less 
> useful version of --clear, for which the primary motivation was "we 
> messed 
> up".
> On 29 Oct 2014 16:05, "Tim Graham"  wrote:
>
>> For other readers, my analysis of the issue and why I don't think 
>> it's appropriate can be found on the ticket where the idea was first 
>> raised: https://code.djangoproject.com/ticket/23724
>>
>> On Wednesday, October 29, 2014 11:34:02 AM UTC-4, Prathik Rajendran M 
>> wrote:
>