Document that migrations must have dependencies in order to access other apps' models

[Richard Eames]

When using migrations.RunPython the first parameter passed to the function is documented as being equivalent to South's orm['app.Model']. In South, the orm has a complete view of all the models, whereas the app parameter only contains apps/models for which the current migration depends on.

I've attached a simple project. To demonstrate this issue, run python manage.py migrate in the app.
The project contains 3 apps: spam, eggs, and cheese. There are dependencies between spam and eggs, but cheese is isolated. I created an empty migration in eggs, and print all the models I can find via the apps parameter. I was expecting it to output all of the models in all three apps, but instead it only prints the models for which the migration depends on.

The apps models are as follows:
eggs: Egg (links to spam.Beef)
cheese: Cheese (no links)
spam: Beef (no links), Potato( links to spam.Beef)

I created an empty migration in eggs which lists all the models in the apps parameter, this is what it prints:

# print(cls) for cls in (for cls in  apps.get_app_configs())
AppConfigStub: eggs
class 'Egg'
AppConfigSub: spam
class 'Beef'
class 'Potato'
----
# print(cls) for cls in apps.get_models()
class 'Egg'
class 'Beef'
class 'Potato'

Notice how it neglects to print out anything from the 'cheese' app.

[Markus Holtermann]

Thank you for the report, but I can't see a new feature request in here, so changing this to "Bug".

I can confirm that behavior but I don't think this is really a bug. If you need the Cheese model in your migration, add the appropriate migration as a dependency. Closing it as invalid.

Adding ('cheese', '0001_initial'), in ('eggs', '0002_auto_20140822_2124') shows the expected behavior:

$ python manage.py migrate
Operations to perform:
  Apply all migrations: sessions, admin, eggs, contenttypes, cheese, spam, auth
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying cheese.0001_initial... OK
  Applying spam.0001_initial... OK
  Applying eggs.0001_initial... OK
  Applying eggs.0002_auto_20140822_2124...<django.apps.registry.Apps object at 0x7f83152f5f10>
<AppConfigStub: cheese>
<class '__fake__.Cheese'>
<AppConfigStub: eggs>
<class '__fake__.Egg'>
<AppConfigStub: spam>
<class '__fake__.Beef'>
<class '__fake__.Potato'>
----
<class '__fake__.Cheese'>
<class '__fake__.Egg'>
<class '__fake__.Beef'>
<class '__fake__.Potato'>
 OK
  Applying sessions.0001_initial... OK

Please re-open the ticket with a descriptive explanation you'd like to see implemented as a new feature.

[Richard Eames]

I see two options here.

• First, RunPython could be documented better to explicitly say that the app parameter not exactly like south's orm parameter, and instead only includes models for which the migration depends on.
• Second, would be to augment the app parameter so that if it can't find the requested model, it'll then try to find it from django.apps.apps, I'm not sure what the ramifications of this are though, but it's how I would expect it to work given the current documentation.

I'd be happy to send a PR on either of these, but I'd likely needs some guidance on the second one.

[Tim Graham]

I think improving the documentation is the way to go.

[Richard Eames]

First draft of better documentation: ​https://github.com/django/django/pull/3127

I think the language could be simplified a lot, any suggestions?

[Richard Eames]

New pull request which fixes the commit message from the previous one. The documentation is also simplified as suggested from the other PR.

​https://github.com/django/django/pull/3129

[Tim Graham <timograham@…>]

In 4dd5c8581d89a9f8e1e34e14c682584e562bf8b1:

Fixed #23349 -- Clarified details about RunPython's apps argument.