[Django] #33196: AppConfig.label identifier enforcement unnecessarily complicates upgrades for some apps

7 views
Skip to first unread message

Django

unread,
Oct 14, 2021, 2:48:00 PM10/14/21
to django-...@googlegroups.com
#33196: AppConfig.label identifier enforcement unnecessarily complicates upgrades
for some apps
------------------------------------------------+------------------------
Reporter: Simon Weber | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Core (Other) | Version: 3.2
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
------------------------------------------------+------------------------
[https://code.djangoproject.com/ticket/32285 #32285] introduced a new
ImproperlyConfigured exception when an app label isn't a valid python
identifier. This was intended to prevent confusion caused by periods in
app labels.

But, this also prevents using app labels containing things like hyphens,
which seem to still work fine when the check is removed. There's a few
mentions online where this has caused surprises, such as for
[https://github.com/FortAwesome/Font-Awesome/issues/17801 fontawesome] and
[https://github.com/sehmaschine/django-grappelli/issues/957 django-
greppelli]. I suspect this will get worse as we get closer to 3.1 support
ending.

Notably,
[https://docs.djangoproject.com/en/3.2/ref/applications/#django.apps.AppConfig.label
the docs] say the label //should// be an identifier, not that it //must//.
So, what do you think about changing the exception to something that can
be overridden, like a warning or system check? This is still a strong
signal to users about the source of potential problems, but also saves a
lot of pain in cases like mine -- as it stands, I'd need to update
thousands of previously-working references across project source,
migrations, and databases.

I'd be happy to write the patch if we can agree on an approach.

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

Django

unread,
Oct 14, 2021, 2:48:43 PM10/14/21
to django-...@googlegroups.com
#33196: AppConfig.label identifier enforcement unnecessarily complicates upgrades
for some apps
-------------------------------------+-------------------------------------

Reporter: Simon Weber | Owner: nobody
Type: | Status: new
Cleanup/optimization |

Component: Core (Other) | Version: 3.2
Severity: Normal | Resolution:

Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Simon Weber):

* cc: Simon Weber (added)


--
Ticket URL: <https://code.djangoproject.com/ticket/33196#comment:1>

Django

unread,
Oct 15, 2021, 12:34:18 AM10/15/21
to django-...@googlegroups.com
#33196: AppConfig.label identifier enforcement unnecessarily complicates upgrades
for some apps
-------------------------------------+-------------------------------------

Reporter: Simon Weber | Owner: nobody
Type: | Status: closed
Cleanup/optimization |

Component: Core (Other) | Version: 3.2
Severity: Normal | Resolution: wontfix

Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Mariusz Felisiak):

* cc: Carlton Gibson (added)
* status: new => closed
* resolution: => wontfix


Comment:

Using `AppConfig.label` other than valid Python identifier has never been
officially supported. Removing this exception would also force changing
this long-standing decision and we'd have to add tests for such apps.

> So, what do you think about changing the exception to something that can
be overridden, like a warning or system check?

I don't think that's an option.

Please start a discussion on the DevelopersMailingList and
[https://docs.djangoproject.com/en/stable/internals/contributing/triaging-
tickets/#closing-tickets follow the triaging guidelines with regards to
wontfix tickets], if you don't agree.

--
Ticket URL: <https://code.djangoproject.com/ticket/33196#comment:2>

Reply all
Reply to author
Forward
0 new messages