Code

Opened 18 months ago

Closed 18 months ago

Last modified 18 months ago

#19650 closed New feature (duplicate)

Add command option to ignore error when collecting static files.

Reported by: zyegfryed Owned by: nobody
Component: contrib.staticfiles Version: master
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: yes UI/UX: no

Description

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.

Attachments (0)

Change History (7)

comment:1 Changed 18 months ago by aaugustin

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to duplicate
  • Status changed from new to closed

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.

comment:2 Changed 18 months ago by zyegfryed

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.

comment:3 Changed 18 months ago by aaugustin

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.

comment:4 Changed 18 months ago by zyegfryed

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.

comment:5 Changed 18 months ago by aaugustin

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!

comment:6 Changed 18 months ago by zyegfryed

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.

comment:7 Changed 18 months ago by aaugustin

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

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.