Re: Overwrite mode in collectstatic

2014-10-29 Thread 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

Re: Overwrite mode in collectstatic

2014-10-29 Thread 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

Re: Overwrite mode in collectstatic

2014-10-29 Thread 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/

Re: Overwrite mode in collectstatic

2014-10-29 Thread 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

Re: Overwrite mode in collectstatic

2014-10-29 Thread 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 ST

Re: Overwrite mode in collectstatic

2014-10-29 Thread 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

Re: Overwrite mode in collectstatic

2014-10-29 Thread 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

Re: Overwrite mode in collectstatic

2014-10-29 Thread 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 ti

Re: Overwrite mode in collectstatic

2014-10-29 Thread 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 initi

Overwrite mode in collectstatic

2014-10-29 Thread 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