Opened 8 years ago

Last modified 8 months ago

#27747 new New feature

Add signals for Django management commands

Reported by: Dmitry Gladkov Owned by: nobody
Component: Core (Management commands) Version: dev
Severity: Normal Keywords:
Cc: Ülgen Sarıkavak Triage Stage: Someday/Maybe
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Related PR: https://github.com/django/django/pull/7857

Suggested example usage (I know that a string can't be a signal sender, this is just for illustrating the point):

from django.core.management import signals


def handle_pre(sender, instance):
    instance.stdout.write('Hello World')

def handle_post(sender, instance):
    instance.stdout.write('Bye World')

signals.pre_command.connect(handle_pre, sender='runserver')
signals.post_command.connect(handle_post, sender='runsever')

Reasoning:

Currently overriding of commands in Django can only be achieved by shadowing existing commands using INSTALLED_APPS initialization order. This is a perfectly good solution if a user needs to completely override a command, but it's not ideal for extending/adding functionality to existing commands. Extending the same command from different apps will not work as only the extended command from the latest INSTALLED_APPS entry will run (see Example 2).

Some examples of actions that can be achieved using singals:

  1. Pulling remote translations before compilemessages.
  2. Showing coverage or/and generating xml report after test.
  3. Running optipng on collected static images after collectstatic
  4. Displaying useful information like outdated package versions before runserver.

Change History (4)

comment:1 by Tim Graham, 8 years ago

Triage Stage: UnreviewedSomeday/Maybe

I'd like to see a consensus on the DevelopersMailingList before accepting this feature. Adam already offered an opinion, "If there are other use cases I think they'd also normally be better handled by more specific signals, e.g. post_migrate, rather than a generic all-commands signal." but this should be proposed on a separate thread.

comment:2 by Matthew Schinckel, 5 years ago

The one I have in mind is being able to fire off a seperate process when starting runserver (for instance, to make sure that our JS build pathway stuff has a "watch" server running).

comment:3 by Carlton Gibson, 5 years ago

For runserver, in particular, I'm suspecting that, at this late stage, they'll be some kind of rewrite making it async, to use presumably asyncio. The autoreloader in the particular seems to be crying out for this... As such, I'd suggesting adding functionality as part of that to control subprocesses (or whatever else) rather than using signals.

comment:4 by Ülgen Sarıkavak, 8 months ago

Cc: Ülgen Sarıkavak added
Note: See TracTickets for help on using tickets.
Back to Top