Poetry virtualenvs.in-project configuration and repository exclusion boundaries

Poetry's virtualenvs.in-project setting places the managed environment inside the project directory, which simplifies container builds and removes dependence on a shared cache path. The tradeoff is that the environment now sits within the source tree, where standard version-control and packaging workflows may treat it as project content unless explicitly excluded.

The uncertainty is where Poetry's responsibility ends and the user's begins. The setting changes only the environment's storage location; it does not alter how version-control or container build systems treat that directory. Exclusion therefore depends entirely on project-level ignore rules, and an incomplete configuration can expose the environment path, installed packages, and absolute interpreter references.

For teams adopting this setting across multiple projects, the open question is whether Poetry offers any configuration guardrails to warn about or prevent unignored in-project environments, or whether every exclusion must be managed manually per repository. Because guardrail behavior may differ across Poetry releases, the exact boundary should be confirmed against the installed version.

Does Poetry provide any built-in detection for unexcluded in-project virtualenv directories? If not, what is the recommended configuration pattern for enforcing exclusion across repositories without relying on global Git templates? Should virtualenvs.in-project be avoided in favor of centralized cache storage when the project directory is synced to public or shared locations?