My team currently relies on docker compose to run our integration tests with pytest. We use docker compose to start services like mysql, redis, AWS localstack. We run our tests within a container containing both the app source code and the test environment and rely on the other docker compose services for our integration tests. I have a Python + Django + Pants proof of concept operating right now where: 1. Each app source code is packaged in a PEX folder 2. The PEX folder is copied to a Docker image 3. The app runs on a container service with docker compose 4. The app source code is volume mounted to the container to enable automatic reloading. 5. The app and tests use different resolves. Is there a way to support our current workflow of executing pytest within a docker compose container? My first thought was to package a PEX file containing both the app source code + dependencies and the testing source code + dependencies.

Your thought sounds like a plausible way to get something working along the same vein as what you currently do, but I'm not sure of the details (and there might be something crucial that stops it working). If you can change how you approach testing (I understand that this may not be possible or desirable!), pants might be able to do it more "naturally". In particular, you could potentially run tests within a

docker_environment

container (https://www.pantsbuild.org/2.20/docs/using-pants/environments), but this won't integrate with the docker-compose services in the same way.

Thanks Huon! Do you have any suggestions for how I could build the PEX file containing both the app source code and the testing code? I'm not sure how to build a PEX from two resolves. For the more natural approach, I suppose I could use pytest-docker to start the docker compose services and call them from the pants docker environment test container, just from outside of the docker compose network.