Previously, using a single Dockerfile with it's associated .dockerignore, it worked fine. However, when trying to follow this through with docker compose, it now fails to work. I will provide my structure.

I have uploaded my folder structure to https://imgur.com/65bjhat for easy reading.

My Dockerfile is,

# Use the official Python image as a base image
FROM python:3.9

Prevents Python from writing pyc files to disc (equivalent to python -B option)
ENV PYTHONDONTWRITEBYTECODE 1

Prevents Python from buffering stdout and stderr (equivalent to python -u option)
ENV PYTHONUNBUFFERED 1

WORKDIR /app

COPY . /app/

RUN pip install -r requirements.txt

My .dockerignore is,

venv/*
**/migrations
.dockerignore
Dockerfile
images/*

My docker-compose.yaml is

services:
  web:
    build: ./app
    command: python manage.py runserver 0.0.0.0:8000
    volumes:
      - ./app:/usr/src/app/
    ports:
      - "8000:8000"
    env_file:
      - ./.dev.env
    depends_on:
      - db
  db:
    image: postgres:16
    volumes:
      - postgres_data:/var/lib/postgresql/data/
    environment:
      - POSTGRES_USER=admin
      - POSTGRES_PASSWORD=admin
      - POSTGRES_DB=radix_fitness_postgresql_db

volumes:
  postgres_data:

I run this using,

docker compose -f compose-dev.yaml up

However, when looking inside my container, everything inside my .dockerignore is still prevent such as my migration folders, venv, etc...

The only thing I did was switch to docker compose, but it seems to be treated identically as my Dockerfile inside of the app directory should be using the .dockerignore. I wonder if COPY is overriding the behaviour of .dockerignore?

Isolation

The purpose of virtualenv is to isolate the system's packages from your app packages so that you don't have any version conflicts etc.

That makes sense because if you have installed python on your regular OS there might be multiple apps using python and every app might require different packages/versions.

But in a docker container your app is the only app requiring python, so there are actually only the packages installed, that your app needs.

So there is no point in using a virtualenv inside a docker container. You could also ask yourself why you don't create another virtualenv inside a virtualenv? Simply because there is no need to because it is already isolated.

But: The system installs a lot of packages by default that might conflict with app's packages

I've read this argument multiple times and they even posted some screenshots showing a lot of packages installed on the system by default.

So I checked what the official python package actually installs:

docker run python pip list
Package Version 
---------- ------- 
pip 21.1.2 
setuptools 57.0.0
wheel 0.36.2

As you can see there are no unnecessary packages installed like urllib, requests, etc.

The only time you get a lot of unwanted stuff is if you don't use the official image but instead use for example ubuntu and manually install python and pip etc.

But in that case, it was your decision to have unwanted stuff already installed...

Conclusion

As you can see there is no reason to use virtualenv inside a docker container, if you use the official images.

If you have multiple python apps that need different packages, create separate images for them and use something like docker-compose to manage them.

If you don't need real isolation (virtualenv isn't real isolation from the host os, since you can still access memory, disk space, etc.), why use containers at all?

Just install everything on the host OS (with venvs) or install another OS in a virtual machine and install everything there.