#27590: Allow configuration of where to save staticfiles manifest.
-------------------------------------+-------------------------------------
Reporter: David Sanders | Owner: Jarosław
Type: | Wygoda
Cleanup/optimization | Status: assigned
Component: contrib.staticfiles | Version: 1.10
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by David Sanders):
Kevin, I think you're neglecting how `collectstatic` is used, and has been
historically used. Changing the default to storing the manifest in the
codebase would be a breaking change for some users. The
`ManifestFilesMixin` hashes files based on content, and the content is
going to depend on people's configurations, and the content will likely
differ depending on the settings used between development and production.
Minifying JS for production is a common use-case, but not for development.
If the manifest by default lives in the codebase, it would both need to be
re-generated after any changes (change in development process), and would
end up with the output for the development environment. Django would
probably need to give a large caveat to ignore the file for source control
otherwise users will shoot themselves in the foot quite often.
The issue I originally brought up with `S3BotoStorage` is that
`ManifestFilesMixin` is a mixin, so adding that to a storage class like
`S3BotoStorage` means it will read and write the manifest from that
storage - in that case from S3. Changing the behavior so that the manifest
doesn't use that storage class could be unintuitive for users. It will
have particular ramifications to how and when they call `collectstatic`
for their deployments - when using a class like `S3BotoStorage` that sends
the files to remote storage, they may not be currently invoking
`collectstatic` at a point where it can write out the manifest into the
codebase and have that change be persistent and make it into the
deployment of the code to production as well. So there'd be a lot of
assumptions about how people are currently using it.
I haven't looked at this issue in 4 years, so that's going from memory.
But I don't believe there's a simple "change the default location"
solution given how many ways `collectstatic` might be used - you're
probably going to break it for somebody. If there were a clear win here I
think I probably would have just made a PR instead of this issue. :-) I
spent a decent amount of time thinking through the problem before punting
it to this issue. I fear if you make it a hard-coded change to the
default, even with a deprecation cycle you'll end up with people coming
out of the woodwork on why they *have* to have it working the way it
originally did, and if there's no configuration ability then you've got a
problem there.
--
Ticket URL: <https://code.djangoproject.com/ticket/27590#comment:13>
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/068.f1b882619dca35f4db7fe5b35f4496de%40djangoproject.com.
