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" <timog...@gmail.com <javascript:>> > 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 <javascript:>. >> To post to this group, send email to django-d...@googlegroups.com >> <javascript:>. >> 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 >> >> <https://groups.google.com/d/msgid/django-developers/e16d9821-95ca-43c8-930b-3e05f3a447d0%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> 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.
