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
Copy file name to clipboardExpand all lines: {{cookiecutter.project_slug}}/README.md
+10-4Lines changed: 10 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -69,7 +69,13 @@ The changes to those files only affect the local development environment, not th
69
69
70
70
For example, the directory with the backend code is mounted as a Docker "host volume" (in the file `docker-compose.dev.volumes.yml`), mapping the code you change live to the directory inside the container. That allows you to test your changes right away, without having to build the Docker image again. It should only be done during development, for production, you should build the Docker image with a recent version of the backend code. But during development, it allows you to iterate very fast.
71
71
72
-
There is also a commented out `command` override (in the file `docker-compose.dev.command.yml`), if you want to enable it, uncomment it. It makes the backend container run a process that does "nothing", but keeps the process running. That allows you to get inside your living container and run commands inside, for example a Python interpreter to test installed dependencies, or start the development server that reloads when it detects changes.
72
+
There is a command override in the file `docker-compose.dev.command.yml` that runs `/start-reload.sh` (included in the base image) instead of the default `/start.sh` (also included in the base image). It starts a single server process (instead of multiple, as would be for production) and reloads the process whenever the code changes. As it is in `docker-compose.dev.command.yml`, it only applies to local development. Have in mind that if you have a syntax error and save the Python file, it will break and exit, and the container will stop. After that, you can restart the container by fixing the error and running again:
73
+
74
+
```bash
75
+
docker-compose up -d
76
+
```
77
+
78
+
There is also a commented out `command` override (in the file `docker-compose.dev.command.yml`), you can uncomment it and comment the default one. It makes the backend container run a process that does "nothing", but keeps the process running. That allows you to get inside your living container and run commands inside, for example a Python interpreter to test installed dependencies, or start the development server that reloads when it detects changes, or start a Jupyter Notebook session.
73
79
74
80
To get inside the container with a `bash` session you can start the stack with:
75
81
@@ -91,7 +97,7 @@ root@7f2607af31c3:/app#
91
97
92
98
that means that you are in a `bash` session inside your container, as a `root` user, under the `/app` directory.
93
99
94
-
There is also a script `/start-reload.sh` to run the debug live reloading server. You can run that script from inside the container with:
100
+
There you use the script `/start-reload.sh` to run the debug live reloading server. You can run that script from inside the container with:
95
101
96
102
```bash
97
103
bash /start-reload.sh
@@ -103,11 +109,11 @@ bash /start-reload.sh
103
109
root@7f2607af31c3:/app# bash /start-reload.sh
104
110
```
105
111
106
-
and then hit enter. That runs the debugging server that auto reloads when it detects code changes.
112
+
and then hit enter. That runs the live reloading server that auto reloads when it detects code changes.
107
113
108
114
Nevertheless, if it doesn't detect a change but a syntax error, it will just stop with an error. But as the container is still alive and you are in a Bash session, you can quickly restart it after fixing the error, running the same command ("up arrow" and "Enter").
109
115
110
-
...this previous detail is what makes it useful to have the container alive doing nothing and then, in a Bash session, make it run the debugging server.
116
+
...this previous detail is what makes it useful to have the container alive doing nothing and then, in a Bash session, make it run the live reload server.
0 commit comments