Poetry in-project .venv vs cache virtualenvs for reproducible CI builds

Context

Our team uses Poetry (1.x, recent releases) for several Python services built in CI and packaged into Docker images. We hit friction because Poetry's default places virtual environments in a per-user cache directory, so the environment path differs between local machines, CI runners, and containers.

Goal

Pick one canonical virtualenv placement policy for all repos so that CI paths stay predictable, Docker builds can copy or reference the environment reliably, and teammates do not break each other's setups when a runner cache is cleared.

Trade-off

Setting virtualenvs.in-project = true gives a stable .venv path inside the repo, which helps scripts and image builds, but duplicates environments per clone and risks accidental commits if .gitignore is missed. The default cache location saves disk and isolates environments, but the path is machine-dependent and disappears when caches are pruned.

Questions

• For CI and container builds, is an in-project .venv the safer default, or are there documented downsides we are missing?
• If we switch an existing project, does Poetry require recreating the environment, and will stale paths break poetry run?
• Is there a supported way to enforce one setting team-wide rather than relying on each developer's local poetry config?