1.5: syntax of AUTH_USER_MODEL

[Anil]

I have the following filesystem structure:

project

project/app1

project/app1/models.py <--- class MyUser(AbstractBaseUser)

project/project

project/project/settings.py

project/project/urls.py

...

I set my AUTH_USER_MODEL to 'project.app1.models.MyUser', I get error:

auth.user: AUTH_USER_MODEL is not of the form 'app_label.app_name'.

I tried also doing something like '..app1.models.MyUser', but that didn't work either or simply 'project.MyUser'. None of these are working.

In the settings.py file, is my model in the path? How do I reference it?

Thanks

[Tom Christie]

You don't mention 'app1.MyUser', which is what I think it should be.

[Anil]

Thanks, yup! I just figured it out too. I didn't realize all the "apps" are in the path as well.

Anil

[Tomas Neme]

> Thanks, yup! I just figured it out too. I didn't realize all the "apps" are
> in the path as well.

the apps aren't NECESSARILY in the path. Django has a concept of app
label, which is the name of the directory where the models module
exists.

For example, django-cms has plugins, which in order to use, you need
to add to INSTALLED_APPS:

'cms.plugins.text',
'cms.plugins.picture'

but the app label of these plugins are just 'text' and 'picture'
respectively, and the "app model" path to their models are just
'text.TextPlugin', and 'picture.PicturePlugin'.

This is, IMO, the biggest and most stupid problem in django core
design, because it stops you from having an otherwise completely legal
configurations, like having a 'cms.plugins.picture' app alongside a
'myproject.custom.picture' one which might do something completely
different. I.E.: you can't have apps with repeated app labels even if
there's no python path conflict between them.

I don't know what the reason behind this is. I know it allows you to
make a model part of any given app regardless of where it's located
(via Meta.app_label), but this could very easily be extended (in a
backwards-incompatible way, I'm afraid) to require to be the fully
qualified name of the app package

--
"The whole of Japan is pure invention. There is no such country, there
are no such people" --Oscar Wilde

|_|0|_|
|_|_|0|
|0|0|0|

(\__/)
(='.'=)This is Bunny. Copy and paste bunny
(")_(") to help him gain world domination.

[Michael K]

On Monday, October 29, 2012 11:09:11 AM UTC-4, Tomas Neme wrote:

This is, IMO, the biggest and most stupid problem in django core
design, because it stops you from having an otherwise completely legal
configurations, like having a 'cms.plugins.picture' app alongside a
'myproject.custom.picture' one which might do something completely
different. I.E.: you can't have apps with repeated app labels even if
there's no python path conflict between them.

I don't know what the reason behind this is. I know it allows you to
make a model part of any given app regardless of where it's located
(via Meta.app_label), but this could very easily be extended (in a
backwards-incompatible way, I'm afraid) to require to be the fully
qualified name of the app package

This is actually a good feature for Django to have.  By enforcing app labels, you enforce data integrity at the application level, not just the database level.  I used to think this was horrible as well until I built a work-around for it and then had all kinds of database integrity issues.

In addition, if an application by the same name is being used in multiple places, you should instead manage the different use with URL patterns and not try to rig it otherwise.  If it's a completely different application than the others, the option I choose is to rename the app's folder and update my INSTALLED_APPS accordingly.  If you didn't write the application and it's not truly decoupled, you may have to make other changes.

--Michael