Add functionality to handle keyboard prompts during migrations for automated deployments

[Kay]

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

[Tim Graham]

I don't think the problem of running management commands with a particular set of keyboard inputs is a problem we should try to solve. That seems brittle and not something we should encourage.

The ability to programmatically delete stale content types seems like a reasonable request. Feel free to open a separate ticket. I'm not entirely happy with your patch since the proposed force_remove kwarg causes the interactive kwarg to be ignored which seems a bit confusing, but maybe it's acceptable. I don't have an alternate proposal at the moment.

[Kay]

Replying to timgraham:

I don't think the problem of running management commands with a particular set of keyboard inputs is a problem we should try to solve. That seems brittle and not something we should encourage.

The ability to programmatically delete stale content types seems like a reasonable request. Feel free to open a separate ticket. I'm not entirely happy with your patch since the proposed force_remove kwarg causes the interactive kwarg to be ignored which seems a bit confusing, but maybe it's acceptable. I don't have an alternate proposal at the moment.

Before I open a new ticket I'd like some clarification.

My solution doesn't ignore interactive; it actually gives the developer the option *to* interact by responding 'yes' to the change automatically. It does this only when the function is invoked in the specific migration file.

What would you like a new ticket say? If this is a problem the team is interested in addressing, I can just as easily modify this ticket to be clearer, but the problem itself won't be any different in a new ticket. Am I misunderstanding what you're proposing? Thanks.

[Tim Graham]

The title seems to suggest building a framework that's capable of responding to input prompts when they appear. This seems quite different from the solution of allowing one particular function to be invoked in a particular way (bypassing the input prompt). I would expect the title of the new ticket to be something like "Add a function to delete stale content types that doesn't require interaction".

What I meant about ignoring interactive is that there isn't a behavior difference between:

update_contenttypes(interactive=True, force_remove=True)
update_contenttypes(interactive=False, force_remove=True)

interactive has no effect if force_remove=True. Since update_contenttypes() isn't a documented, public API, one solution might be to create a new simpler function in somewhere like contenttypes/utils.py with less confusing arguments (it might invoke update_contenttypes() with some 'private' argument like force_remove as you suggested).