You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Configure batches of Django management commands in your settings files and run them all at once.
17
-
For example, batch together your common database maintenance tasks, deployment routines or any
18
-
other set of commands you need to run together. This helps single source general site maintenance
19
-
into your settings files keeping your code base [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself).
16
+
Configure batches of Django management commands in your settings files and run them all at once. For example, batch together your common database maintenance tasks, deployment routines or any other set of commands you need to run together. This helps single source general site maintenance into your settings files keeping your code base [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself).
20
17
21
18
## Example
22
19
23
-
Let's define two named routines, "package" and "deploy". The package routine will be a collection
24
-
of commands that we typically run to generate package artifacts (like migrations and transpiled
25
-
javascript). The deploy routine will be a collection of commands we typically run when deploying
26
-
the site for the first time on a new server or when we deploy version updates on the server.
20
+
Let's define two named routines, "package" and "deploy". The package routine will be a collection of commands that we typically run to generate package artifacts (like migrations and transpiled javascript). The deploy routine will be a collection of commands we typically run when deploying the site for the first time on a new server or when we deploy version updates on the server.
27
21
28
22
**Routine commands are run in the order they are registered, or by [priority](#priorities).**
29
23
24
+
There are two types of commands, management commands and system commands. The management commands will be called in the same process space as routine unless --subprocess is specified in which case they will use the same management script as routine was invoked with or whatever value you supply to --manage-script. System commands are always invoked as subprocesses.
25
+
30
26
In our settings file we may define these routines like this:
31
27
32
28
```python
33
-
from django_routines import RoutineCommand, command, routine
29
+
from django_routines import (
30
+
ManagementCommand,
31
+
SystemCommand,
32
+
command,
33
+
system,
34
+
routine
35
+
)
34
36
35
37
# register routines and their help text
36
38
routine(
@@ -43,19 +45,21 @@ routine(
43
45
# you may register commands on a routine after defining a routine (or before!)
44
46
command("package", "makemigrations")
45
47
command("package", "renderstatic")
48
+
system("package", "poetry", "build")
46
49
47
50
routine(
48
51
"deploy",
49
52
"Deploy the site application into production.",
50
53
51
-
# you may also specify commands inline using the RoutineCommand dataclass
52
-
RoutineCommand(
54
+
# you may also specify commands inline using the ManagementCommand dataclass
prepare="Generate artifacts like migrations and transpiled javascript.",
@@ -98,7 +102,7 @@ For example to deploy our demo on a new server we would run:
98
102
99
103
## Settings
100
104
101
-
The [RoutineCommand](https://django-routines.readthedocs.io/en/latest/reference.html#django_routines.RoutineCommand) dataclass, [routine](https://django-routines.readthedocs.io/en/latest/reference.html#django_routines.routine) and [command](https://django-routines.readthedocs.io/en/latest/reference.html#django_routines.command) helper functions in the example above make it easier for us to work with the native configuration format which is a dictionary structure defined in the ``DJANGO_ROUTINES`` setting attribute. For example the above configuration is equivalent to:
105
+
The [ManagementCommand](https://django-routines.readthedocs.io/en/latest/reference.html#django_routines.ManagementCommand) dataclass, [routine](https://django-routines.readthedocs.io/en/latest/reference.html#django_routines.routine) and [command](https://django-routines.readthedocs.io/en/latest/reference.html#django_routines.command) helper functions in the example above make it easier for us to work with the native configuration format which is a dictionary structure defined in the ``DJANGO_ROUTINES`` setting attribute. For example the above configuration is equivalent to:
"help_text": "Generate pre-package artifacts like migrations and "
135
141
"transpiled javascript.",
@@ -186,3 +192,7 @@ When specifying arguments you may add them to the command tuple OR specify them
186
192
```
187
193
188
194
*You only need to install [django_typer](https://github.com/bckohan/django-typer) as an app if you want to use the shellcompletion command to [enable tab-completion](https://django-typer.readthedocs.io/en/latest/shell_completion.html) or if you would like django-typer to install [rich traceback rendering](https://django-typer.readthedocs.io/en/latest/howto.html#configure-rich-stack-traces) for you - which it does by default if rich is also installed.*
195
+
196
+
## Rationale
197
+
198
+
When does it make sense to configure routines in Django settings? Its generally convenient to group common management pathways into easily discoverable and executable aggregations of subroutines. This is usually donein supporting shell scripts or just files and in most cases that is appropriate. If your goal is to keep your Django deployment as tight and self contained as possible and the deployment is not generally very complex, using django-routines can make a lot of sense. It can eliminate extra dependencies on a shell scripting environment or just files and can keep this logic packaged with your installable wheel.
0 commit comments