Adding a function to to Django to programmatically delete stale content types

[Proto]

Original closed ticket: https://code.djangoproject.com/ticket/24820 

The content of it is as follows:

While removing models in one of my migrations, I was prompted by Django to input yes/no. For development, this is no problem. For automatic deployments it is.

I want to know if there exists or if it's possible to add functionality to Django to do this. I've created a modification which works, but also want to learn if anyone else has solved this problem differently.

Modifying the deployment file to include --noinput does not solve this problem (it basically defaults to no which ultimately doesn't remove the model).

The patch I've created seems to be working just fine. My solution involves editing the contenttypes to take an additional argument. The argument can be invoked inside a migration file so that I have full control over when it's used. You can view the code below.

Link to diff for the patch I created: ​https://github.com/Protosac/django/commit/d98fff8219469a363493e8d8455c7ffb2430d36f

How to use this patch: http://pastebin.com/UFr6LBAZ

A member of the Django core team expressed interest in a solution that would address this problem, but rejected my specific implementation above. I wanted to open a discussion to learn how other developers were dealing with this issue to try to come up with a better way. 100 brains are better than one and all that :)

Any one else encounter this problem and solve it differently? It was recently suggested to create a Django utility module instead, which I think is a great suggestion, but given my limited experience with the framework I don't see how this is possible without altering `update_contenttypes`  or overriding it. It seems at some point I must intervene at that method.

[Tim Graham]

My suggestion wasn't that update_contenttypes() couldn't be modified, but rather that it might be better to expose the desired functionality as a separate utility method to avoid having to explain in the documentation how the interactive and force_remove keywords interact (probably the utility method wouldn't need to allow the user to customize either of these).

[Proto]

Oh! I see. I think I interpreted as "this would be a good utility module". Small misunderstanding.

Even so, the mechanisms that cause Django to prompt for interaction are within that method. To make another method to me indicates overriding the one I just modified. But it's as I said I've only just begun using Django so I'm not very well versed in how the community prefers to tackle these problems.

So I'd still like to hear how others would approach this. I think that many others must have encountered this issue (especially during automatic deployments) so it'd be good to see how they've gotten around this. Thanks.