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

[Piotr Czachur <zimnyx@…>]

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!

[Russell Keith-Magee]

Dupe of #12288.

[Piotr Czachur <zimnyx@…>]

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.

[Piotr Czachur <zimnyx@…>]

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.