Opened 6 years ago

Closed 6 years ago

#28764 closed Cleanup/optimization (duplicate)

Store staticfiles.json with code

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

Description

When you run collectstatic with the ManifestStaticFilesStorage backend, it creates a mapping from raw filenames to versioned filenames and stores it in a file called staticfiles.json alongside the static files. My suggestion is to store that file with the code instead.

The static directory is a strange place for it, since it is not itself a static file, nor does it have anything to do with serving static files. What it is is a configuration file that affects what Django inserts into dynamically-generated pages. It has more in common with settings.py than a static file.

Now, that hardly matters in a traditional deployment where static files are served from the same machine as Django; it's just one directory versus another. However, this approach has some serious drawbacks in the common deployment scenario of hosting the static files separately (from S3, for example).

One problem is that Django has to fetch a remote file as part of its startup. That has a performance penalty, places limits on the server, and adds an additional point of failure. More seriously, it can actually break your site during deployment. Fundamentally this is because the generated mapping is correct only for the commit that produced it, but it's being uploaded to a global location where it affects the behavior of all extant servers. So any servers that are running (or restarted) between the time collectstatic is run and when the new code is fully rolled out can behave incorrectly.

For an example of this problem in the field, see this blog post. As noted there, it's possible to change the manifest location by supplying your own custom storage backend. My suggestion would be to change this in Django itself, though, since I don't see the advantage of the current behavior.

Change History (4)

comment:1 by Kevin Christopher Henry, 6 years ago

Related: #27541.

comment:2 by Tim Graham, 6 years ago

Type: UncategorizedCleanup/optimization

Duplicate of #27590?

comment:3 by Kevin Christopher Henry, 6 years ago

Interesting, I didn't see that one. I'll add a comment over there...

comment:4 by Tim Graham, 6 years ago

Resolution: duplicate
Status: newclosed
Note: See TracTickets for help on using tickets.
Back to Top