#32987 closed New feature (fixed)
Warn user if they attempt to have multiple templatetag libraries with the same name
Reported by: | Daniel | Owned by: | Shreya Bamne |
---|---|---|---|
Component: | Template system | Version: | 3.2 |
Severity: | Normal | Keywords: | template, check |
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
If a project has mulitple apps with templatetags with the same module name, django will load each of them, but drop all but the last one, and not inform the user at all, making it quite hard to diagnose.
For example, if you have:
- blog/templatetags/navigation_tags.py
- news/templatetags/navigation_tags.py
- pages/templatetags/navigation_tags.py
then try to use them in a template:
{% load navigation_tags %}
then only one of these will be loaded - and there's no report that there is a problem - but if you attempt to use one of the filters / tags from one of the libraries that's not the loaded one, it throws a generic template syntax error saying it's an invalid tag / filter.
Proposed solution:
Add a new 'check' to the django checks that warns the user if there are multiple templatetag libraries with the same name.
see PR:
Change History (16)
comment:1 by , 3 years ago
Description: | modified (diff) |
---|---|
Summary: | If multiple apps have templatetags modules with the same name, it silently drops all but one. → Warn user if they attempt to have mulitple templatetag libraries with the same name |
comment:2 by , 3 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
Triage Stage: | Unreviewed → Accepted |
comment:3 by , 3 years ago
Summary: | Warn user if they attempt to have mulitple templatetag libraries with the same name → Warn user if they attempt to have multiple templatetag libraries with the same name |
---|
comment:4 by , 3 years ago
Needs documentation: | set |
---|---|
Needs tests: | set |
Patch needs improvement: | set |
comment:5 by , 3 years ago
The PR (https://github.com/django/django/pull/14735) mentioned in the ticket was closed due to inactivity. I would like to continue working on this. Would the correct next steps be to assign this ticket to myself, open a new PR and link the old one there? I am new to the Django community, any inputs are appreciated. Thank you.
comment:6 by , 3 years ago
Owner: | changed from | to
---|
I have started working on this ticket and assigning the ticket to me.
comment:7 by , 3 years ago
Continuing on the previous work done on this ticket, here is the link to the new PR: https://github.com/django/django/pull/15005
comment:8 by , 3 years ago
Needs documentation: | unset |
---|---|
Needs tests: | unset |
Patch needs improvement: | unset |
comment:9 by , 3 years ago
Needs tests: | set |
---|---|
Patch needs improvement: | set |
comment:10 by , 3 years ago
Needs tests: | unset |
---|---|
Patch needs improvement: | unset |
Triage Stage: | Accepted → Ready for checkin |
follow-up: 14 comment:13 by , 2 years ago
I wonder if we should reconsider the new behavior here. The problem is that if in your project dependencies (which make sometimes a big list) you have two tag libraries with the same name, the project won't be able to migrate to Django 4.1. It's rather easily fixable when one of the libs is in your project, but not when they both are from external deps. See https://github.com/jazzband/sorl-thumbnail/issues/713
Could we at least make the check a warning, so it can be silenced?
comment:14 by , 2 years ago
Replying to Claude Paroz:
Could we at least make the check a warning, so it can be silenced?
Sounds reasonable, see PR.
Sounds reasonable.