Opened 10 months ago

Closed 6 months ago

Last modified 6 months ago

#23366 closed Bug (fixed)

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

Reported by: stevejalim Owned by: yakky
Component: Migrations Version: 1.7
Severity: Normal Keywords:
Cc: yakky 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 MarkusH)

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

  • Component changed from Uncategorized to Migrations
  • Easy pickings set
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Type changed from Uncategorized to Bug
  • Version changed from 1.6 to 1.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 10 months ago by andrewgodwin

  • Triage Stage changed from Unreviewed to Accepted

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 10 months ago by x110dc

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

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 10 months 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 setting.py AUTH_USER_MODEL = 'accounts.MyUser' and now run

$ ./manage.py migrate --list

The error message:

Traceback (most recent call last):
  File "./manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/var/dev/project/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 385, in execute_from_command_line
    utility.execute()
  File "/var/dev/project/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 377, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/var/dev/project/local/lib/python2.7/site-packages/django/core/management/base.py", line 288, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/var/dev/project/local/lib/python2.7/site-packages/django/core/management/base.py", line 338, in execute
    output = self.handle(*args, **options)
  File "/var/dev/project/local/lib/python2.7/site-packages/django/core/management/commands/migrate.py", 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/migrate.py", line 307, in show_migration_list
    loader = MigrationLoader(connection)
  File "/var/dev/project/local/lib/python2.7/site-packages/django/db/migrations/loader.py", line 48, in __init__
    self.build_graph()
  File "/var/dev/project/local/lib/python2.7/site-packages/django/db/migrations/loader.py", 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/loader.py", 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 10 months ago by lukas-schulze (previous) (diff)

comment:6 Changed 10 months ago by sharifmamun

  • Owner changed from nobody to sharifmamun
  • Status changed from new to assigned

comment:7 Changed 8 months ago by timgraham

  • Has patch set
  • Needs tests set
  • Version changed from 1.7-rc-3 to 1.7

PR 3234 needs tests.

comment:8 Changed 8 months ago by yakky

  • Owner changed from sharifmamun to yakky

Assigning this to me to write tests

comment:9 Changed 8 months ago by yakky

I cannot reproduce this either.

Steps taken:

  • django-admin startproject whatever
  • Create an accounts application with models.py containing the MyUser model detailed above
  • Add accounts to INSTALLED_APPS
  • Add AUTH_USER_MODEL = 'accounts.MyUser' at the bottom of the settings
  • run ./manage.py 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 8 months ago by yakky

  • Cc yakky added

comment:11 Changed 8 months ago by yakky

I set up a test to test the failure

comment:12 Changed 6 months ago by MarkusH

  • Description modified (diff)

comment:13 Changed 6 months ago by timgraham

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 6 months ago by Tim Graham <timograham@…>

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

In b4bdd5262b18644456d12a00d475adf9897a9255:

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

comment:15 Changed 6 months 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