Add command option to ignore error when collecting static files.

[Sébastien Fievet]

Scenario

A common case scenario is when using CachedStaticFilesStorage storage and a file that is missing.
The post-processing phase fails hard and exits abruptly, leaving the project in an incoherent state.

Solution

The goal is to add an option to collectstatic command in order to ignore errors raised on post-processing phase when files are missing.
The pacth will be mostly an adapted back-port of the pull-request ​#PR17 made for the legacy django-staticfiles app.

[Aymeric Augustin]

This was previously reported in #18958 and it was decided that "errors should never pass silently".

#18986 suggests a way to make the problem easier to debug.

[Sébastien Fievet]

I understand that "errors should never pass silently", because it comes with the Zen of Python that we all love and share. However, it also continues with : "Unless explicitly silenced.". That's what my solution was aiming to: adding an optional flag on the command line to explicitly ignore post-processing errors and leave the processed file unchanged, when you know what and why you are doing it.

That way, when someone missed the error before going on production, it can still brings the server back in a running state using that flag option, thus leaving time to fix the broken library in between.

So the question is: Can/Should we leave a production server on broken state for one missing image referenced deep inside some CSS ? Can/Should we provide a way to circumvent it and let the app running nonetheless ?

I hope you'll have a second thought about it.

In the meantime, I totally agree with #18986, which will help a lot in order to quickly find a missing file. I might try to tackle it.

[Aymeric Augustin]

If you put things in production with settings you haven't tested and are unable to perform a rollback, there's only so much Django can do to help you.

In this case the fastest solution would be to switch back to StaticFilesStorage.

[Sébastien Fievet]

We're talking about adding a flag like the -f/--force option from git add or git push. Something that is really common and sometime useful even if not always the way to go. But we know what we're doing when using it.

A file can be missing because someone hasn't tested enough it's app. But it can also occurs due to network/provider issue when uploading to/retrieving from FTP/S3/whatever or because it has been corrupted somehow. It happens. We have to be aware of it and the default behavior is the right one because it warns us about it. However, Django should be able to help us to bring back some working state - all in all, cache busting is an option and shouldn't be a deployment blocker - letting us time to tackle the missing file issue. That's the point of this optional flag.

[Aymeric Augustin]

The ​contributing guide recommends writing to the django-developers mailing list if you disagree with the decision to close a ticket as wontfix.

Otherwise, as this ticket is closed, your comments are most likely not going to attract enough attention to move things forwards.

Thanks!

[Sébastien Fievet]

Forget about my comment, delving into #18986 made me realize that what is suggested is way better than my solution, moving it to the next level.
Thanks for your time. My excuse having wasting yours.

[Aymeric Augustin]

No problem — I went through pretty much the same steps on this topic a few months ago :)