Opened 12 months ago

Closed 12 months ago

Last modified 9 months ago

#22848 closed Bug (fixed)

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

Reported by: valberg Owned by: nobody
Component: Migrations Version: master
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

Description

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

Change History (10)

comment:1 Changed 12 months ago by valberg

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Summary changed from Admin initial migration run before app containing AUTH_USER_MODEL to Admin 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 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.

comment:2 Changed 12 months ago by valberg

  • Has patch set

I've got rid of the error like this:

  • django/db/migrations/loader.py

    diff --git a/django/db/migrations/loader.py b/django/db/migrations/loader.py
    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 Changed 12 months ago by valberg

  • Needs tests set

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

But it needs some tests.

comment:4 Changed 12 months ago by valberg

  • 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 Changed 12 months ago by andrewgodwin

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 Changed 12 months ago by Andrew Godwin <andrew@…>

  • Resolution set to fixed
  • Status changed from new to closed

In 2b79be2beee8531ab1ef4efca75589705774d8f7:

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

comment:7 Changed 12 months ago by Andrew Godwin <andrew@…>

In 11b8e6154b32c0a46c8910c21070692f3d08f6b4:

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

comment:8 Changed 9 months ago by stevejalim

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 Changed 9 months ago by timgraham

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 Changed 9 months ago by stevejalim

Thanks Tim

New ticket #23366 created

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