Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#22848 closed Bug (fixed)

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

Reported by: Vidir Valberg Gudmundsson Owned by: nobody
Component: Migrations Version: dev
Severity: Release blocker Keywords:
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: yes Patch needs improvement: yes
Easy pickings: no UI/UX: no


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:

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

Change History (10)

comment:1 by Vidir Valberg Gudmundsson, 10 years ago

Summary: Admin initial migration run before app containing AUTH_USER_MODELAdmin initial migration can't find AUTH_USER_MODEL when running makemigrations for the first time

The summary was misleading. It is not when the migrations get applied, but when they are about to be created. Basically the 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.

comment:2 by Vidir Valberg Gudmundsson, 10 years ago

Has patch: set

I've got rid of the error like this:

  • django/db/migrations/

    diff --git a/django/db/migrations/ b/django/db/migrations/
    index 0d961c2..359d99e 100644
    a b class MigrationLoader(object):  
    150150            # so we're fine.
    151151            return
    152152        if key[0] in self.migrated_apps:
     153            # Fix #22484 where admin 0001_initial migration relies on a
     154            # non-existing migration when running makemigrations with a custom
     155            # user model
     156            if key[0] in settings.AUTH_USER_MODEL:
     157                return
    153158            try:
    154159                if key[1] == "__first__":
    155160                    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.

comment:3 by Vidir Valberg Gudmundsson, 10 years ago

Needs tests: set

Created a PR:

But it needs some tests.

comment:4 by Vidir Valberg Gudmundsson, 10 years ago

Patch needs improvement: set

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

comment:5 by Andrew Godwin, 10 years ago

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.

comment:6 by Andrew Godwin <andrew@…>, 10 years ago

Resolution: fixed
Status: newclosed

In 2b79be2beee8531ab1ef4efca75589705774d8f7:

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

comment:7 by Andrew Godwin <andrew@…>, 10 years ago

In 11b8e6154b32c0a46c8910c21070692f3d08f6b4:

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

comment:8 by Steve Jalim, 10 years ago

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?

comment:9 by Tim Graham, 10 years ago

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.

comment:10 by Steve Jalim, 10 years ago

Thanks Tim

New ticket #23366 created

Note: See TracTickets for help on using tickets.
Back to Top