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.
* cc: Simon Weber (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/33196#comment:1>
* 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>