Code

Opened 4 years ago

Closed 4 years ago

#12287 closed (wontfix)

Application name must be unique in a project - silent sideeffect when it's not

Reported by: Piotr Czachur <zimnyx@…> Owned by: nobody
Component: Uncategorized Version: master
Severity: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

Guys,

1) django accepts multiple applications with the same name in INSTALLED_APPS, but such thing has many unpleasant side effects, many are silent until you really dig in.
Django code should check whether there are applications with the same name (like "foo.auth", "bar.auth") in INSTALLED_APPS, and if they are found, exception should be thrown: "Django doesn't support multiple applications with the same name".
2) Why it isn't mentioned in documentation? It's should be written in bold.
3) During the time I migrated to Django - which was 2 months ago - I experienced many silent side effect when this "unique app name" constraint was violated: for example, when running test for given application:

python manage.py test auth

Django will run tests only for 1st found application with "auth" name, others are just quietly skipped. It's just wrong, I'd like to see exception or tests should be run for all applications with "auth" name.
4) My conclusion is that all this kind of problems occured because Django is not using python path for applications. I mean we put aplication path "package.appname" in INSTALLED_APPS, but Django cares only about last path component which is application name. Why Django refuses to use standard python thing?

I put it all here to provide you better explanation of my point, but to be precise I'll create separate tickets for docs, and tests.
Cheers!

Attachments (0)

Change History (3)

comment:1 Changed 4 years ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to duplicate
  • Status changed from new to closed

Dupe of #12288.

comment:2 Changed 4 years ago by Piotr Czachur <zimnyx@…>

  • Resolution duplicate deleted
  • Status changed from closed to reopened

Why you closed this ticket without a word of explanation?
I assume that setting this as duplicate of #12288 means that you just want to add documentation, and leave this as it is, but maybe this idea is worth more time.

It would be much more flexible if under one project, applications were registered with user-defined name, for example:

INSTALLED_APPS =  {
    'django_auth' : 'django.contrib.auth',
    'my_auth' : 'my.package.path.auth',
}

So one could run test separately for both applications:

manage.py test django_auth
manage.py test my_auth

...and those applications would use different database tables:

django_auth_ModelName # for django_auth
my_auth_ModelName # for my_auth

So like today, Django would have application with names, but that names wouldn't collide when we got multiple applications with the same package name (like django.contrib.auth and my.package.path.auth). In this concept author of a project defines application name instead of author of an application.

comment:3 Changed 4 years ago by Piotr Czachur <zimnyx@…>

  • Resolution set to wontfix
  • Status changed from reopened to closed

Like joshuajonah suggested on #django my approach wouldn't work because as convention (third-party) applications are in pythonpath, and they would have bunch of import issues.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.