#28764: Store staticfiles.json with code
-------------------------------------+-------------------------------------
               Reporter:  Kevin      |          Owner:  nobody
  Christopher Henry                  |
                   Type:             |         Status:  new
  Uncategorized                      |
              Component:             |        Version:  1.11
  contrib.staticfiles                |
               Severity:  Normal     |       Keywords:
           Triage Stage:             |      Has patch:  0
  Unreviewed                         |
    Needs documentation:  0          |    Needs tests:  0
Patch needs improvement:  0          |  Easy pickings:  0
                  UI/UX:  0          |
-------------------------------------+-------------------------------------
 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
 [https://devblog.kogan.com/blog/a-hidden-gem-in-
 django-1-7-manifeststaticfilesstorage 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.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/28764>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.d17bbf14ed387b49ebd234dd1e70f983%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to