Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#23366 closed Bug (fixed)

Workaround for `ValueError: Dependency on app with no migrations` in #22848 may need attention

Reported by: Steve Jalim Owned by: Iacopo Spalletti
Component: Migrations Version: 1.7
Severity: Normal Keywords:
Cc: Iacopo Spalletti Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: yes Patch needs improvement: no
Easy pickings: yes UI/UX: no

Description (last modified by Markus Holtermann)

May I suggest either an extension to the fix made in #22848 or a note in documentation about it?

(TLDR for that ticket: starting a project with a custom user model and no migrations yet led to an exception when makemigrations was run, so @andrewgodwin added a special case for the creation of a first migration)

I just hit what appeared to be the same issue myself, found the ticket, checked my Django version (1.7 RC3) and thought all should be well, but I thought it still wasn't working for me until I actually read the patch and saw why:

There's still a subtle gotcha where migrate --list will still throw the dependency error, while makemigrations <app name> will happily run. So if someone 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.

One solution would be to extend the no-migrations behaviour to --list. Alternatively if we collectively just 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, but it would need a little background added in the same patch, too. Anyone disagree?

Change History (15)

comment:1 Changed 9 years ago by Steve Jalim

Component: UncategorizedMigrations
Easy pickings: set
Type: UncategorizedBug
Version: 1.61.7-rc-3

I'd actually call this a release blocker, given that it stops development in its tracks if you fall into the hole. However, I'm not familiar enough with the project triage process to make that call.

comment:2 Changed 9 years ago by Andrew Godwin

Triage Stage: UnreviewedAccepted

I agree this is an issue but not a release blocker; it's not a crash but an exit with a genuine error message.

That said, the fix is relatively simple, in that we should make --list also enable the mode where it gets to ignore these errors.

comment:3 Changed 9 years ago by Daniel Craigmile

I have no particular expertise here but I'm at the DjangoCon sprint so I thought I'd see if I could help. :-) There's two things on this ticket that confuse me: (1) there's no --list option to makemigrations. Did you mean migrate? Or has this changed since the ticket was created? and (2) I can't reproduce the error. I started a new (empty) Django project, added the sample custom User model from #22848, tried a migrate --list and didn't get any errors. Can you show exactly what sequence created the error?

comment:4 Changed 9 years ago by Steve Jalim

Yes, my typo. It would have been ./manage migrate --list (I have aliases set up, so conflated the terms).

Interesting that you can't reproduce it. Will try to find time to replicate it in a standalone proj

comment:5 Changed 9 years ago by Lukas Schulze

I'm using Django 1.7 and in a standalone project you can easily reproduce it with an AbstractBaseUser:

class MyUser(AbstractBaseUser):
    email = models.EmailField('E-Mail', unique=True)
    USERNAME_FIELD = 'email'

Add to your AUTH_USER_MODEL = 'accounts.MyUser' and now run

$ ./ migrate --list

The error message:

Traceback (most recent call last):
  File "./", line 10, in <module>
  File "/var/dev/project/local/lib/python2.7/site-packages/django/core/management/", line 385, in execute_from_command_line
  File "/var/dev/project/local/lib/python2.7/site-packages/django/core/management/", line 377, in execute
  File "/var/dev/project/local/lib/python2.7/site-packages/django/core/management/", line 288, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/var/dev/project/local/lib/python2.7/site-packages/django/core/management/", line 338, in execute
    output = self.handle(*args, **options)
  File "/var/dev/project/local/lib/python2.7/site-packages/django/core/management/commands/", line 60, in handle
    return self.show_migration_list(connection, args)
  File "/var/dev/project/local/lib/python2.7/site-packages/django/core/management/commands/", line 307, in show_migration_list
    loader = MigrationLoader(connection)
  File "/var/dev/project/local/lib/python2.7/site-packages/django/db/migrations/", line 48, in __init__
  File "/var/dev/project/local/lib/python2.7/site-packages/django/db/migrations/", line 239, in build_graph
    parent = self.check_key(parent, key[0])
  File "/var/dev/project/local/lib/python2.7/site-packages/django/db/migrations/", line 163, in check_key
    raise ValueError("Dependency on app with no migrations: %s" % key[0])
ValueError: Dependency on app with no migrations: accounts
Last edited 9 years ago by Lukas Schulze (previous) (diff)

comment:6 Changed 9 years ago by S.M. Al Mamun

Owner: changed from nobody to S.M. Al Mamun
Status: newassigned

comment:7 Changed 9 years ago by Tim Graham

Has patch: set
Needs tests: set
Version: 1.7-rc-31.7

PR 3234 needs tests.

comment:8 Changed 9 years ago by Iacopo Spalletti

Owner: changed from S.M. Al Mamun to Iacopo Spalletti

Assigning this to me to write tests

comment:9 Changed 9 years ago by Iacopo Spalletti

I cannot reproduce this either.

Steps taken:

  • django-admin startproject whatever
  • Create an accounts application with containing the MyUser model detailed above
  • Add accounts to INSTALLED_APPS
  • Add AUTH_USER_MODEL = 'accounts.MyUser' at the bottom of the settings
  • run ./ migrate --list
  • Outputs the migrations for admin, auth, contenttypes, sessions

Tested on 1.7c3, 1.7, 1.7.1 versions

Apparently nothing has changed in MigrationLoader class since mid-june, so no idea what triggered the message in the first place

comment:10 Changed 9 years ago by Iacopo Spalletti

Cc: Iacopo Spalletti added

comment:11 Changed 9 years ago by Iacopo Spalletti

I set up a test to test the failure

comment:12 Changed 9 years ago by Markus Holtermann

Description: modified (diff)

comment:13 Changed 9 years ago by Tim Graham

Not sure why the test doesn't reproduce the failure, but I can reproduce this manually. Since apps without migrations will be obsolete in 1.9, I don't think this is worth spending any more time on so I'll just commit this without a test.

comment:14 Changed 9 years ago by Tim Graham <timograham@…>

Resolution: fixed
Status: assignedclosed

In b4bdd5262b18644456d12a00d475adf9897a9255:

Fixed #23366 -- Fixed a crash with the migrate --list command.

comment:15 Changed 9 years ago by Tim Graham <timograham@…>

In f461bc02cbfa7c04748e4b2392586fa3835330b1:

[1.7.x] Fixed #23366 -- Fixed a crash with the migrate --list command.

Backport of b4bdd5262b18644456d12a00d475adf9897a9255 from master

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