Missing default callable breaks migration

[Richard Buck]

If I try to change the default on a model field from one callable to another, the migration will fail if the old callable is no longer available. It appears this is because the migration system tries to call the old callable to determine if it returns a different value from the new. 

I don't think this should cause an error; it's not unusual to delete/rename a function used as a field default. 

Moreover, I think comparing output from the old default is a bad idea; I initially had migration failure because I had changed the default from a function that returned timezone-aware dates to one that returned timezone-naive dates. 

Hence I think this general behaviour is a bug that needs to be fixed; exceptions trying to compare old and new defaults during migration should be handled and not break the migration.

Note that I was able to work around this by modifying the previous default in the earlier migration file.

[Tim Graham]

Please read https://docs.djangoproject.com/en/stable/topics/migrations/#historical-models

In particular, "References to functions in field options such as upload_to and limit_choices_to and model manager declarations with managers having use_in_migrations = True are serialized in migrations, so the functions and classes will need to be kept around for as long as there is a migration referencing them."

The crash about timezone/non-timezone comparison is tracked in https://code.djangoproject.com/ticket/24822. Feel free to try to implement a patch if you are interested and able!

[Simon Charette]

I would add that since migration files are normal Python modules you can simply replace the previously imported callable in the referencing migrations by inlining it.

Simon