Admin initial migration can't find AUTH_USER_MODEL when running makemigrations for the first time

[Vidir Valberg Gudmundsson]

Defining a custom user model (in app 'testapp' and with settings.AUTH_USER_MODEL = 'testapp.CustomUser'):

from django.db import models
from django.contrib.auth.models import AbstractUser

class CustomUser(AbstractUser):
    foo = models.CharField(max_length=255)

And trying to make an initial migration, results in an error:

$ ./manage.py makemigrations
Traceback (most recent call last):
  File "/Users/valberg/.virtualenvs/django17/lib/python3.4/site-packages/django/db/migrations/loader.py", line 155, in check_key
    return list(self.graph.root_nodes(key[0]))[0]
IndexError: list index out of range

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "./manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/Users/valberg/.virtualenvs/django17/lib/python3.4/site-packages/django/core/management/__init__.py", line 385, in execute_from_command_line
    utility.execute()
  File "/Users/valberg/.virtualenvs/django17/lib/python3.4/site-packages/django/core/management/__init__.py", line 377, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/Users/valberg/.virtualenvs/django17/lib/python3.4/site-packages/django/core/management/base.py", line 288, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/Users/valberg/.virtualenvs/django17/lib/python3.4/site-packages/django/core/management/base.py", line 337, in execute
    output = self.handle(*args, **options)
  File "/Users/valberg/.virtualenvs/django17/lib/python3.4/site-packages/django/core/management/commands/makemigrations.py", line 54, in handle
    loader = MigrationLoader(None)
  File "/Users/valberg/.virtualenvs/django17/lib/python3.4/site-packages/django/db/migrations/loader.py", line 47, in __init__
    self.build_graph()
  File "/Users/valberg/.virtualenvs/django17/lib/python3.4/site-packages/django/db/migrations/loader.py", line 224, in build_graph
    parent = self.check_key(parent, key[0])
  File "/Users/valberg/.virtualenvs/django17/lib/python3.4/site-packages/django/db/migrations/loader.py", line 159, in check_key
    raise ValueError("Dependency on app with no migrations: %s" % key[0])
ValueError: Dependency on app with no migrations: testapp

[Vidir Valberg Gudmundsson]

The summary was misleading. It is not when the migrations get applied, but when they are about to be created. Basically the 0001_initial.py migration in contrib.admin is looking for an __first__ migration for the app that has AUTH_USER_MODEL. This does of course not exist because we are in the process of creating it when this error occurs.

[Vidir Valberg Gudmundsson]

I've got rid of the error like this:

django/db/migrations/loader.py

@@ -150 +150 @@
             # so we're fine.
             return
         if key[0] in self.migrated_apps:
+            # Fix #22484 where admin 0001_initial migration relies on a
+            # non-existing migration when running makemigrations with a custom
+            # user model
+            if key[0] in settings.AUTH_USER_MODEL:
+                return
             try:
                 if key[1] == "__first__":
                     return list(self.graph.root_nodes(key[0]))[0]

But I'm not sure if this breaks anything. I'm running the testsuite right now and will report back. If this is an okay approach I'll make a PR.

[Vidir Valberg Gudmundsson]

Created a PR: ​https://github.com/django/django/pull/2818

But it needs some tests.

[Vidir Valberg Gudmundsson]

Apparently the patch reintroduces #22563 (ValueError: Lookup failed for model referenced by field admin.LogEntry.user:) when running migrate in #22783.

[Andrew Godwin]

The patch isn't the correct fix; that check is in loader for a reason.

I'm tempted to just say "don't switch the setting till you've made a migration", as otherwise you are literally telling Django to hang its contrib apps off of an app with nothing, which is definitely incorrect, but I'm going to see if I can ignore this error during makemigrations only.

[Andrew Godwin <andrew@…>]

In 2b79be2beee8531ab1ef4efca75589705774d8f7:

Fixed #22848: Ignore no-migrations errors during makemigrations only

[Andrew Godwin <andrew@…>]

In 11b8e6154b32c0a46c8910c21070692f3d08f6b4:

[1.7.x] Fixed #22848: Ignore no-migrations errors during makemigrations only

[Steve Jalim]

May I suggest either an extension to this fix or a note in documentation about it?

Context: I just hit this issue myself, found the ticket, checked my Django version and thought all should be well, but I thought it still wasn't working for me until I actually read the patch.

There's still a subtle gotcha where makemigrations --list will still throw the dependency error, while makemigrations <app name> will happily run. So if somoene gets Dependency on app with no migrations when starting runserver and they then try to check their migrations list, they will be prevented from doing so and they have no cue to as to what they can do to remedy things.

It's a corner case, sure, but likely will lead to user frustration for those stuck in that corner.

If you want a patch for the docs, I'd be happy to submit one. I think the an aside in the custom user docs seems a sensible place. Anyone disagree?

[Tim Graham]

I'd recommend to create a new ticket as comments on closed tickets often don't get attention. In any case, I'll be happy to review any docs you write.

[Steve Jalim]

Thanks Tim

New ticket #23366 created