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" <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/373226bc-f46a-4b82-91e5-d70fcd6d6542%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
