Opened 10 years ago
Closed 10 years ago
#24890 closed New feature (fixed)
Add warning to collectstatic when static files have clashing names
Reported by: | Markus Amalthea Magnuson | Owned by: | Markus Amalthea Magnuson |
---|---|---|---|
Component: | contrib.staticfiles | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | markus.magnuson@… | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
If you have a project with several apps, some of which have static files directly in their static
folder named identically, one of them will always be overwritten by the other when running collectstatic
. The recommendation, and what is noted in the documentation, is to namespace by keeping all static files belonging to an app in an additional subdirectory in the static
folder named like the app name. But if you're not doing that, the result can be very confusing. I've seen many developers run into this and spending quite some time before figuring it out through the documentation or otherwise.
I think there should be a default system check that looks for clashing static file names as described above, and warn if there are files that will overwrite each other when running collectstatic
.
Change History (13)
comment:1 by , 10 years ago
Summary: | Add system check for static files that will always be overwritten on collectstatic → Add warning to collectstatic when static files have clashing names |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 10 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
That sounds reasonable. Would it make sense to make such check as part of the management command itself? I'll probably work on this during the DjangoCon Europe sprints, so I'm assigning this ticket to myself for now :)
comment:3 by , 10 years ago
Yes, I envisioned the warning as part of collectstatic's logging output.
comment:4 by , 10 years ago
Has patch: | set |
---|
I've open a pull request for this: https://github.com/django/django/pull/4740
A couple of thoughts:
- Would it make more sense to use
warnings.warn()
instead of logging with level 0? - Any pointers on how to write tests for this change?
comment:5 by , 10 years ago
I did another commit to change the log level from 0 to 1, since it would show up in e.g. test output otherwise.
comment:6 by , 10 years ago
Needs tests: | set |
---|
You can grep for stdout=out
in Django's test suit to see how to capture output from management commands.
comment:9 by , 10 years ago
Needs tests: | unset |
---|
comment:11 by , 10 years ago
I've updated the pull request according to code review. Should I squash all of the commits into a single one?
comment:12 by , 10 years ago
Cc: | added |
---|---|
Patch needs improvement: | unset |
I'm not sure a system check is a good idea since it seems such a check would involve a lot of disk reading and it could be expensive to do that each time the dev server is restarted (currently all system checks are simply static code analysis). Perhaps a warning when running collecstatic would be a better approach?