Does Poetry isolate optional extras per project in shared virtual environments?

Answer

No. Poetry does not provide per-project isolation for optional extras when projects share a single virtual environment. Optional packages are not isolated branches in the resolver. When an extra is activated, its dependencies become regular nodes in the same dependency graph and are subject to the same conflict resolution as mandatory dependencies. In a shared venv, installing an extra for one project makes that package available to all projects using that environment.

Confirmed facts

• The lock file stores extras under a separate extras section, and optional dependencies are only installed when the extra is explicitly requested, e.g. poetry install --extras <extra>.
• Poetry builds one dependency graph per install operation. Optional packages are included in the graph only when the corresponding extra is activated, but once activated they participate in version selection and conflict resolution like mandatory dependencies.
• There is no built-in mechanism to scope optional extras to a single pyproject.toml. Isolation would require separate virtual environments or using --without/--only flags to exclude unwanted extras.
• When multiple projects share a virtual environment, an extra installed for one project remains present in the environment and can affect other projects that do not declare that extra.

Likely explanation for the observed behavior

The resolver was refactored across the 1.x series and continues into the 2.x series. The change improved determinism and performance, but it did not introduce per-project or per-extra isolation. Optional nodes are therefore fully connected to the rest of the graph rather than being isolated branches. This means version constraints from an activated extra can influence the version chosen for a shared dependency, and that version will be written to the shared environment.

Practical verification steps for this case

1. Create two minimal projects with different optional extras that depend on different version ranges of the same package.
2. Point both projects at the same virtual environment.
3. Run poetry install --extras <extra-one> for the first project and inspect the environment with pip list and poetry show --tree.
4. Run poetry install --extras <extra-two> for the second project and observe whether the first optional package is upgraded, downgraded, or remains.

To give a precise recommendation for your setup, what Poetry version and how is the shared virtual environment created and used? Specifically, are you using poetry env use to point multiple projects to one venv, or a manually shared .venv path? That detail changes whether --without exclusion or separate environments is the safer mitigation.