This file never worked, it caused a circular import loop since it attempts to `from bakerydemo.settings.dev import *` but the dev settings does:
```python
try:
from .local import * # noqa
except ImportError:
pass
```
Fixed the `setup.sh` script to set the correct settings module environment variable
Fixes#68
This caused a spurious warning when running `docker compose` commands because `$PYTHONPATH` is not defined on the docker _host_ and docker attempted to interpret it as if it were any other environment variable e.g. `$DB_USER`, etc.
All it accomplished was to add a non-existent directory to the path:
```bash
docker compose run web bash
root@2bc54a69fd5c:/code/bakerydemo# echo $PYTHONPATH
/code/wagtail:/code/bakerydemo:$PYTHONPATH
root@2bc54a69fd5c:/code/bakerydemo# python -c "import sys; print('\n'.join(sys.path))"
/code/wagtail
/code/bakerydemo
/code/bakerydemo/$PYTHONPATH
/usr/local/lib/python38.zip
/usr/local/lib/python3.8
/usr/local/lib/python3.8/lib-dynload
/usr/local/lib/python3.8/site-packages
/code/willow
```
Fixes#56
- This is function on Windows & Linux, bugs can be raised if needed, see related #46#35#31 (all closed)
- Elasticsearch/Opensearch Docker container is already an issue #3 (still open)
* Create makefile
* Update readme with makefile commands
* Update readme spacing and sh comments
* Add back line that was taken out in readme
* stop and down rename in makefile
* Updates as per feedback
* Update readme to include raw docker commands as well as makefile ones
* Update Dockerfile for Debian Bullseye release
The previously used base image `python:3.7` was changed to now use
Debian Bullseye. This lead to installation issues of `libenchant-dev`
(see #31).
This is now fixed by upgrading the installation command for `libenchant`
to `libenchant-2-dev` (see also https://pkgs.org/search/?q=LIBENCHANT).
Additionally, to avoid similar issues in the future, the Debian version
of the base image is now defined in the `Dockerfile`.
* Upgrade Python base image from 3.7 to 3.8
Automatic container restarts are not necessary in a development context.
Also, working on multiple projects with these settings only leads to
an extreme load on the dev machine, because all the containers from
all the projects are starting when the Docker engine is started.
* Update the README with instructions on getting bakerydemo to use the PostgreSQL database from the adjacent container
* Corrected formatting in README
* Automated setting up bakerydemo to use the postgres service from our docker-compose
* Broke out the initial database stuff into a separate one-time script.
Also enhanced the .dockerignore file to make image builds a lot faster, and added .idea to the .gitignire, so that PyCharm projects won't get added to the repo.
* Reworked the database and Wagtail installation setup
In order to improve the development experience while using docker-wagtail-develop, I reorganized how the database setup is done, and how and when Wagtail gets installed into the python environment inside the docker container. Plus a few other changes.
1. Database. The migration and initial data load steps are now done once, by the user, during initial setup (setup-sb.sh), rather than happening at the start of every `docker-compose up`. This is possible because the postgres data is already being stored in a Docker Volume, so it persists across container executions.
2. Wagtail is now installed into the 'web' docker container by the Dockerfile, rather than docker-compose. This lets Docker skip that step if nothing has changed in Wagtail since the last build (admittedly, not super common, given that this project is for developing Wagtail), and generally makes the whole process a lot cleaner.
3. I added a bunch of stuff to .dockerignore, which significantly cuts down on the 'web' and 'frontend' images filesizes and build times.
4. I gave each of the three containers specific names, so that they can be more easily executed into for things like running manage.py commands or other OS stuff. This resulted in the connect string for the postgres DB needing to be tweaked.
5. I changed the 'frontend' container's copy command for the node_modules folder to use the -u flag, which allows cp to skip any files that haven't changed since the last time the copy was run. This *dramatically* speeds up the startup of the 'frontend' container on all but the very first execution (which does the initial copy into the host's wagtail folder).
I really wanted to find a way to put node_modules into a Docker Volume, but since you can't write to Volumes during the image build process, that unfortunately negates any value-add that we might have gotten from their use in this case.
Sævar Öfjörð Magnússon