"populate() isn't reentrant" masks underlying error

[TK-23]

I'm new to reporting bugs, but have struggled with this one enough that I thought I would formally document an issue we've seen.

In django/django/apps/registry.py (​https://github.com/django/django/blob/20ba3ce4ac8e8438070568ffba76f7d8d4986a53/django/apps/registry.py#L83) there is a line of code that can raise an error when running simple commands like python manage.py runserver:

if self.loading:
                # Prevent reentrant calls to avoid running AppConfig.ready()
                # methods twice.
                raise RuntimeError("populate() isn't reentrant")

The problem is that this generic error can mask the true reason why django will not start up (I've seen the true reason be something like a problem with a version of a Python package needing to be updated, or an import of a module that does not exist elsewhere in the code). Based on a stackoverflow response (​https://stackoverflow.com/questions/27093746/django-stops-working-with-runtimeerror-populate-isnt-reentrant) I've learned to comment out raise RuntimeError("populate() isn't reentrant") and replace it with self.app_configs={}

This way the true error will be exposed when starting up django. I do not know the best way to handle this but before I found this stackoverflow post, we lost a lot of time trying to debug issues. Even knowing this workaround it is a hassle to adjust the django code to see the true error.

I can provide a link to our opensource project with a branch set up to replicate the error if that is helpful.

[Carlton Gibson]

I can provide a link to our opensource project with a branch set up to replicate the error if that is helpful.

Yes please. I would expect that the "true error" would be exposed earlier in the logs, so it would be good to see the reproduce.
Thanks.

[Carlton Gibson]

I'm going to close this as needsinfo for the moment. If you can add a reproduce I'm happy to look at it!

[Timothy Schilling]

I was able to reproduce this by creating a second app named auth. This was fixed in https://code.djangoproject.com/ticket/21679, but there's no check or indication that was the problem.

I believe django.setup eats the ImproperlyConfigured exception that's raised.

[Timothy Schilling]

Moving the self.loading comparison and set after the two known cases of raising ImproperlyConfigured seems to resolve the issue. If I could get some direction regarding how to write that test, I'll get this implemented. That said, I'm not sure this exception case is covered in the tests: ​https://github.com/django/django/commit/7ed20e015335076fc98ad805eaf241f8a0d872d5

[Carlton Gibson]

@Tim — thanks for pursuing this. Can you put what you have in a PR maybe so it's easier to review (and have a play with)? 👍