#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 )
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 by , 10 years ago
Component: | Uncategorized → Migrations |
---|---|
Easy pickings: | set |
Type: | Uncategorized → Bug |
Version: | 1.6 → 1.7-rc-3 |
comment:2 by , 10 years ago
Triage Stage: | Unreviewed → 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 by , 10 years ago
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 by , 10 years ago
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 by , 10 years ago
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
comment:6 by , 10 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:7 by , 10 years ago
Has patch: | set |
---|---|
Needs tests: | set |
Version: | 1.7-rc-3 → 1.7 |
PR 3234 needs tests.
comment:9 by , 10 years ago
I cannot reproduce this either.
Steps taken:
- django-admin startproject whatever
- Create an
accounts
application withmodels.py
containing theMyUser
model detailed above - Add
accounts
toINSTALLED_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 by , 10 years ago
Cc: | added |
---|
comment:12 by , 10 years ago
Description: | modified (diff) |
---|
comment:13 by , 10 years ago
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 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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.