[Django] #32853: apps.get_model in RunPython returning "LookupError: No installed app with label"
Django
label"
------------------------------------------+------------------------
Reporter: Gordon Wrigley | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 3.1
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
------------------------------------------+------------------------
This is just a possible space for catching user errors and warning about
them.
I have two apps, a backfill migration created with --empty and using
RunPython in app A is using apps.get_model to get a model from app B.
However the migration has no dependency on app B.
Depending on runtime ordering of migrations this may cause a LookupError,
or it may work.
It feels like apps.get_model could be noticing that based on the
dependency graph the referenced app/model may not exist.
--
Ticket URL: <https://code.djangoproject.com/ticket/32853>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
label"
Reporter: Gordon Wrigley | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 3.1
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Adam Johnson):
`apps.get_model()` only runs when the migration runs. Are you proposing
that when it runs, it infers that the current migration is reachable
through *some* migration ordering without app B's model being available,
even though in the *current* migration ordering, things are fine? That
seems fairly complicated.
--
Ticket URL: <https://code.djangoproject.com/ticket/32853#comment:1>
Django
label"
Reporter: Gordon Wrigley | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 3.1
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Adam Johnson):
* cc: Adam Johnson (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/32853#comment:2>
Django
label"
Reporter: Gordon Wrigley | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 3.1
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Gordon Wrigley):
Pretty much yes.
I don't know how it works internally, I appreciate the complexity will
depend a lot on how much access it has to the migration DAG when the
individual migrations run.
--
Ticket URL: <https://code.djangoproject.com/ticket/32853#comment:3>
Django
label"
Reporter: Gordon Wrigley | Owner: nobody
Component: Uncategorized | Version: 3.1
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* status: new => closed
* resolution: => wontfix
Comment:
Hey Gordon. Thanks for this.
I'm going to say `wontfix` as it strikes me as not-practical — maybe it's
doable but at what cost vs ''Add the dependency by hand when writing the
migration'', which seems pretty fair (at least at first pass.)
Having said that, if you want to provide a proof-of-concept we can have a
look at it to make a more informed decision.
I hope that makes sense.
--
Ticket URL: <https://code.djangoproject.com/ticket/32853#comment:4>
Django
label"
Reporter: Gordon Wrigley | Owner: nobody
Component: Uncategorized | Version: 3.1
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Gordon Wrigley):
I agree the resolution is easy once you know what the problem is.
The difficult bit is working out what caused the error, especially when it
occurs a month after the missing dependency because some later migration
caused the ordering to change.
It's rather baffling to end up staring at an error that says your app
isn't installed when it manifestly is, and it was working yesterday and is
working in prod.
--
Ticket URL: <https://code.djangoproject.com/ticket/32853#comment:5>
Django
label"
Reporter: Gordon Wrigley | Owner: nobody
Component: Uncategorized | Version: 3.1
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Carlton Gibson):
Sure, and (as I said) happy to look at a suggestion here. My reservation
is that I'm sceptical it would be worth the complexity. (If you're writing
a `RunPython` that uses app B, it's clear — I think — that you should add
the dependency.)
--
Ticket URL: <https://code.djangoproject.com/ticket/32853#comment:6>
Django
label"
Reporter: Gordon Wrigley | Owner: nobody
Component: Uncategorized | Version: 3.1
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Gordon Wrigley):
I don't know if it makes it any easier, but the narrower feature of
requiring a dependency on an app A migration in order to use
`apps.get_model(A, ...)` would probably cover it, it forces you to stop
and think about the dependencies
--
Ticket URL: <https://code.djangoproject.com/ticket/32853#comment:7>