Double public and public_collected directories about docker-django-example

[philgyford]

Sorry, I'd just now realised collectstatic is not run in development and was coming here to correct myself. Apologies; it's hard to follow exactly what's going on.

[nickjj]

Hi,

The (2) /public*/ directories are there to hold your assets in a non-volume mounted location so they never get overwritten by your volumes. These get populated at build time when you build your Docker image, the /public_collected/ directory gets populated when collectstatic gets run based on having set DEBUG=false in your .env at build time.

At runtime (thanks to https://github.com/nickjj/docker-django-example/blob/main/bin/docker-entrypoint-web) the public_collected/ directory gets copied over to /app/public_collected where your volume can take over to allow you to persist files back to your Docker host and potentially serve these assets from a web server not running in Docker such as nginx.

It is pretty convoluted but I don't see a way around all of this. We have to meet 2 criteria here:

• Django does not let you output collectstatic in the same directory where your source is, this means we need 2 sets of public/ directories, I named them accordingly
• We need to build both sets of public files in a non-volume mounted directory but also make them available in a volume at runtime in such a way where existing files in the volume on the Docker host at runtime won't overwrite the newly built public files, this means we need to store both sets of public/ directories in 2 locations

If you have a way to meet both of these criteria in a cleaner way I'm all for improving it, keep in mind it would need to work in development too where assets aren't collected. I'd love to be able to get rid of this workflow.

[philgyford]

Thanks that makes sense. I've only been using this for local development so far, so haven't quite grasped the differences with how it would work in production.

Previously I've only used manage.py runserver during development, not gunicorn, and added "whitenoise.runserver_nostatic" to INSTALLED_APPS if DEBUG=True. Which I think means I don't need to run collectstatic except on the production server (where I wasn't using Docker).

I assume we need to run collectstatic in development because we're using gunicorn?

Now that I'm thinking of using Docker for both dev and production I have this extra level of complication to get my head round I guess!

In my dabblings with Docker and Django I'm always frustrated that dealing with static files ends up being so complicated!

[nickjj]

You don't need to run collectstatic in development.

The exact instructions in the readme file combined with the source code in this repo will work out of the box and your assets will get served in development.

The collection process is mainly around digesting the files with an md5 hash, it's aimed at production although there's nothing stopping you from digesting them manually in development. It happens in production by default due to the Dockerfile having a condition to run it when DEBUG=false:

docker-django-example/Dockerfile

Lines 64 to 66 in b87f465

	RUN if [ "${DEBUG}" = "false" ]; then \
	SECRET_KEY=dummyvalue python3 manage.py collectstatic --no-input; \
	else mkdir -p /app/public_collected; fi