(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 `makemigrations --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?
--
Ticket URL: <https://code.djangoproject.com/ticket/23366>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_better_patch: => 0
* component: Uncategorized => Migrations
* needs_tests: => 0
* version: 1.6 => 1.7-rc-3
* easy: 0 => 1
* needs_docs: => 0
* type: Uncategorized => Bug
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/23366#comment:1>
* stage: Unreviewed => Accepted
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/23366#comment:2>
Comment (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?
--
Ticket URL: <https://code.djangoproject.com/ticket/23366#comment:3>
Comment (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
--
Ticket URL: <https://code.djangoproject.com/ticket/23366#comment:4>
Comment (by lukas-schulze):
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
--
Ticket URL: <https://code.djangoproject.com/ticket/23366#comment:5>
* owner: nobody => sharifmamun
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/23366#comment:6>
* has_patch: 0 => 1
* version: 1.7-rc-3 => 1.7
* needs_tests: 0 => 1
Comment:
[https://github.com/django/django/pull/3234 PR 3234] needs tests.
--
Ticket URL: <https://code.djangoproject.com/ticket/23366#comment:7>
* owner: sharifmamun => yakky
Comment:
Assigning this to me to write tests
--
Ticket URL: <https://code.djangoproject.com/ticket/23366#comment:8>
Comment (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
--
Ticket URL: <https://code.djangoproject.com/ticket/23366#comment:9>
* cc: yakky (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/23366#comment:10>
Comment (by yakky):
I set up a
[https://github.com/yakky/django/commit/624b84a034cb59227330af6fba2bfdba114699f1
test] to test the failure
--
Ticket URL: <https://code.djangoproject.com/ticket/23366#comment:11>
Old description:
> 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 `makemigrations --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?
New description:
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?
--
--
Ticket URL: <https://code.djangoproject.com/ticket/23366#comment:12>
Comment (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.
--
Ticket URL: <https://code.djangoproject.com/ticket/23366#comment:13>
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"b4bdd5262b18644456d12a00d475adf9897a9255"]:
{{{
#!CommitTicketReference repository=""
revision="b4bdd5262b18644456d12a00d475adf9897a9255"
Fixed #23366 -- Fixed a crash with the migrate --list command.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/23366#comment:14>
Comment (by Tim Graham <timograham@…>):
In [changeset:"f461bc02cbfa7c04748e4b2392586fa3835330b1"]:
{{{
#!CommitTicketReference repository=""
revision="f461bc02cbfa7c04748e4b2392586fa3835330b1"
[1.7.x] Fixed #23366 -- Fixed a crash with the migrate --list command.
Backport of b4bdd5262b18644456d12a00d475adf9897a9255 from master
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/23366#comment:15>