[Django] #32938: App name changes and is confusing to use across a project

20 views
Skip to first unread message

Django

unread,
Jul 17, 2021, 6:02:28 AM7/17/21
to django-...@googlegroups.com
#32938: App name changes and is confusing to use across a project
-----------------------------------------+------------------------
Reporter: Michael | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | 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 |
-----------------------------------------+------------------------
I hope this is just a case of "you doing it wrong". This issue has been a
thorn in my side for so long, and is an issue of constant confusion for
me. So like many larger projects, my applications doesnt have all the
django apps in the root folder. I created a framework as follows:

**project_root**
- **core** - contains essentials apps for the framework
- **applib** - contains apps that a certain deployment may or may not
use
- **dist** - contains apps that are only used for a certain
distribution

Now say there is app **foo** within **core**, then from experimentation
(as in things don't work otherwise) one must set:
{{{
# Filename: project_root/core/foo/apps.py
from django.apps import AppConfig

class FooConfig(AppConfig):
name = 'core.foo' # I hope here I am doing it wrong, and this is the
source of trouble
}}}

Okay great so the app name must include the dotted path from the project
root, no problem. So now all the **reverse(...)** and **{% url '...' %}**
use this dotted path app name.

Then say one has an issue of circular imports with models, so one must
lazy import the model name. However it does not use the app name, it uses
some other combination, after trying various ways turns out it must be in
like this:

{{{
# Filename: applib/bar/models.py

class BarModel(models.Model):
foo = models.ForeignKey('foo.FooModel', on_delete=models.PROTECT,
null=True, blank=True)
}}}
Notice how now the appname is '**foo**', whereas most of the time it is
'**core.foo**'.
Additionally with migrations it uses this shorter app name. If one looks
in the django_migration table and migration files, one sees '**foo**'
instead of '**core.foo**' (which is what it was explicitly set to).

Is this not a bit confusing?

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

Django

unread,
Jul 17, 2021, 11:45:03 AM7/17/21
to django-...@googlegroups.com
#32938: App name changes and is confusing to use across a project
-------------------------------+--------------------------------------
Reporter: Michael | Owner: nobody
Type: Uncategorized | Status: closed
Component: Uncategorized | Version: 3.2
Severity: Normal | Resolution: invalid

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 Tim Graham):

* status: new => closed
* resolution: => invalid


Comment:

I don't want to be dismissive of your confusion, but I don't see any
actionable suggestion in this ticket. See
TicketClosingReasons/UseSupportChannels for ways to get help. Feel free to
create a new ticket or repurpose this one if you have some specific
suggestion after your understanding is clarified.

It may help to read about the difference between
[https://docs.djangoproject.com/en/dev/ref/applications/#django.apps.AppConfig.name
AppConfig.name] and
[https://docs.djangoproject.com/en/dev/ref/applications/#django.apps.AppConfig.label
AppConfig.label].

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

Django

unread,
Jul 20, 2021, 6:25:00 AM7/20/21
to django-...@googlegroups.com
#32938: App name changes and is confusing to use across a project
-------------------------------+--------------------------------------

Reporter: Michael | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | 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 Michael):

* status: closed => new
* resolution: invalid =>


Old description:

New description:

{{{
# Filename: applib/bar/models.py

Is this not a bit confusing. What I am suggesting is consistency in the
app.name.
The app name is not clearly define and consistantly applied.
Can we set the app name to be same when importing a model, in migrations,
and in i'ts apps.py name?

--

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

Django

unread,
Jul 20, 2021, 6:27:18 AM7/20/21
to django-...@googlegroups.com
#32938: App name changes and is confusing to use across a project
-------------------------------+--------------------------------------
Reporter: Michael | Owner: nobody
Type: Uncategorized | Status: closed
Component: Uncategorized | Version: 3.2
Severity: Normal | Resolution: invalid

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 Michael):

* status: new => closed
* resolution: => invalid


Comment:

Replying to [comment:1 Tim Graham]:


> I don't want to be dismissive of your confusion, but I don't see any
actionable suggestion in this ticket. See
TicketClosingReasons/UseSupportChannels for ways to get help. Feel free to
create a new ticket or repurpose this one if you have some specific
suggestion after your understanding is clarified.
>
> It may help to read about the difference between
[https://docs.djangoproject.com/en/dev/ref/applications/#django.apps.AppConfig.name
AppConfig.name] and
[https://docs.djangoproject.com/en/dev/ref/applications/#django.apps.AppConfig.label
AppConfig.label].

--
Ticket URL: <https://code.djangoproject.com/ticket/32938#comment:3>

Django

unread,
Jul 20, 2021, 6:59:34 AM7/20/21
to django-...@googlegroups.com
#32938: App name changes and is confusing to use across a project
-------------------------------+--------------------------------------
Reporter: Michael | Owner: nobody
Type: Uncategorized | Status: closed
Component: Uncategorized | Version: 3.2
Severity: Normal | Resolution: invalid

Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------

Old description:

> Is this not a bit confusing. What I am suggesting is consistency in the
> app.name.
> The app name is not clearly define and consistantly applied.
> Can we set the app name to be same when importing a model, in migrations,
> and in i'ts apps.py name?

New description:

{{{
# Filename: applib/bar/models.py

Is this not a bit confusing. What I am suggesting is consistency in the


app.name.
The app name is not clearly define and consistantly applied.
Can we set the app name to be same when importing a model, in migrations,

and in its apps.py name?

--

Comment (by Tim Graham):

> Can we set the app name to be same when importing a model, in

migrations, and in its apps.py name?

[https://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.ForeignKey
Docs for foreign key says], "To refer to models defined in another
application, you can explicitly specify a model with the full application
label. For example, if the Manufacturer model above is defined in another
application called production, you’d need to use: ..."

Perhaps it would help to link `app_label` and "full application label"
(which should perhaps be renamed `app_label`) in this section. In the docs
for `app_label` you can read "It defaults to the last component of name."

I believe this clarifies your confusion.

--
Ticket URL: <https://code.djangoproject.com/ticket/32938#comment:4>

Reply all
Reply to author
Forward
0 new messages