Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#32938 closed Uncategorized (invalid)

App name changes and is confusing to use across a project

Reported by: Michael Owned by: nobody
Component: Uncategorized Version: 3.2
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by Tim Graham)

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. 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?

Change History (4)

comment:1 by Tim Graham, 3 years ago

Resolution: invalid
Status: newclosed

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 AppConfig.name and AppConfig.label.

comment:2 by Michael, 3 years ago

Description: modified (diff)
Resolution: invalid
Status: closednew

in reply to:  1 comment:3 by Michael, 3 years ago

Resolution: invalid
Status: newclosed

Replying to 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 AppConfig.name and AppConfig.label.

comment:4 by Tim Graham, 3 years ago

Description: modified (diff)

Can we set the app name to be same when importing a model, in migrations, and in its apps.py name?

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.

Note: See TracTickets for help on using tickets.
Back to Top