[Django] #27747: Add signals for Django management commands

21 views
Skip to first unread message

Django

unread,
Jan 19, 2017, 8:04:16 AM1/19/17
to django-...@googlegroups.com
#27747: Add signals for Django management commands
-------------------------------------+-------------------------------------
Reporter: Dmitry | Owner: nobody
Gladkov |
Type: New | Status: new
feature |
Component: Core | Version: master
(Management commands) |
Severity: Normal | Keywords:
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
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):
{{{#!python
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`.

--
Ticket URL: <https://code.djangoproject.com/ticket/27747>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Jan 20, 2017, 6:41:52 PM1/20/17
to django-...@googlegroups.com
#27747: Add signals for Django management commands
-------------------------------------+-------------------------------------
Reporter: Dmitry Gladkov | Owner: nobody
Type: New feature | Status: new
Component: Core (Management | Version: master
commands) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Someday/Maybe
Has patch: 0 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Tim Graham):

* stage: Unreviewed => Someday/Maybe


Comment:

I'd like to see a consensus on the DevelopersMailingList before accepting
this feature. Adam already [https://groups.google.com/d/msg/django-
developers/JwYKEemPHFs/zC-Xe_ycBAAJ 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.

--
Ticket URL: <https://code.djangoproject.com/ticket/27747#comment:1>

Django

unread,
Aug 21, 2019, 8:29:21 PM8/21/19
to django-...@googlegroups.com
#27747: Add signals for Django management commands
-------------------------------------+-------------------------------------
Reporter: Dmitry Gladkov | Owner: nobody
Type: New feature | Status: new
Component: Core (Management | Version: master
commands) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Someday/Maybe
Has patch: 0 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Matthew Schinckel):

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).

--
Ticket URL: <https://code.djangoproject.com/ticket/27747#comment:2>

Django

unread,
Aug 22, 2019, 3:35:59 AM8/22/19
to django-...@googlegroups.com
#27747: Add signals for Django management commands
-------------------------------------+-------------------------------------
Reporter: Dmitry Gladkov | Owner: nobody
Type: New feature | Status: new
Component: Core (Management | Version: master
commands) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Someday/Maybe
Has patch: 0 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Carlton Gibson):

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.

--
Ticket URL: <https://code.djangoproject.com/ticket/27747#comment:3>

Django

unread,
Mar 18, 2024, 2:55:48 AM3/18/24
to django-...@googlegroups.com
#27747: Add signals for Django management commands
-------------------------------------+-------------------------------------
Reporter: Dmitry Gladkov | Owner: nobody
Type: New feature | Status: new
Component: Core (Management | Version: dev
commands) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Someday/Maybe
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Ülgen Sarıkavak):

* cc: Ülgen Sarıkavak (added)

--
Ticket URL: <https://code.djangoproject.com/ticket/27747#comment:4>
Reply all
Reply to author
Forward
0 new messages