Problem Django.19 upgrade and circular imports

[Andres Osinski]

Hi everyone! I'm having an issue with circular imports in Django 1.9 that I have not seen in my app, which had been running 1.7 before.

I have a Django app in apps.common, which has its associated apps.common.models too. No imports on __init__.py or anything of the sort.

When I my app in apps.account.models attempts to import apps.common.models, it complains that said module does not exist.

Putting a pdb set_trace() call at the top of apps.common.models and apps.account.models shows that the former executes *before* apps.account.models, so I fail to see how this could result in the posted error.

For the record, both apps use the new AppConfig scheme in their corresponding apps.py file, and the import order in INSTALLED_APPS is:

'apps.common.CommonConfig',

'apps.account.AccountConfig',

...

Has anyone else had a similar issue in this upgrade? Is there anything I can do to diagnose the source of this?

Thanks!

--

Andrés Osinski

[Tim Graham]

No ideas off the top of my head. You could try bisecting to find the commit in Django where the behavior changed.

https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/#bisecting-a-regression

[James Schneider]

Are you bringing in other functions in as part of your imports, or just other models? If you are only bringing in models for use with FK's and M2M's, then I would suggest referring to those models via their text path rather than using the Python class object directly. It avoids needing the import statement during the initial load (which avoids the circular import issue). See the end of this section about referring to models in other applications using a string rather than the real Python object (and make sure to remove the related import statements):

https://docs.djangoproject.com/en/1.9/ref/models/fields/#foreignkey

-James

[Andres Osinski]

The thing is that in my case, I have a model in the 'accounts' app which inherits from a model in 'common', therefore I need the import to happen in one's models.

I've tried this in Django 1.8 and I see the same behavior; therefore the change occurs between the latest versions of 1.7 and 1.8. I'll try with older versions in 1.8 and report back.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2Be%2BciUWHXr6axqA5drrsMnR3%2B9d0D1wBHSK9wQwSmqs52xFAw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Andrés Osinski

[Andres Osinski]

So I've tried going back to Django 1.7 but changing the app configuration to use the AppConfig class and I've hit upon the same issue.

It would seem that part of the key is the fact that when the system hits this line:

/home/osinski/Projects/feastly/apps/account/models.py in <module>()

     11 

     12 from ipdb import set_trace; set_trace()

---> 13 from apps.common.models import CommonInfo

     14 from feastly.paths import get_path

ImportError: No module named common.models

It would appear as though the "common" module hasn't loaded in apps yet. 

Some posts on previous versions of Django have advised that the 'apps' subdirectory should be included in the system path; we have never done this before and thus far things have worked well, however I don't know if this was suppored behavior. The negative to doing that is that I'd have to rename all the imports from 'apps.X' to 'X'.

Does Django support apps that reside in submodules or have I been depending on broken behavior?

--

Andrés Osinski