Does Poetry's default virtualenv location leave production containers without installed dependencies?

A Python service managed with Poetry (assuming the 1.8–2.x configuration model) needs a production image whose runtime interpreter actually contains the packages that poetry install resolves. On a developer workstation this is rarely visible, because the virtualenv is created and activated in place.

By documented default, however, Poetry creates virtualenvs under its cache directory rather than inside the project tree, unless virtualenvs.in-project is enabled or the POETRY_VIRTUALENVS_IN_PROJECT variable is set. In a multi-stage container build that installs dependencies in one stage and copies only application source into the final image, an environment stored in the cache directory would never be carried across stages. The unresolved point is whether the default location can be relied on for image builds at all, or whether the environment must live inside the project tree or be bypassed in favor of the system interpreter.

Does Poetry offer any mechanism besides virtualenvs.in-project for making a cache-directory virtualenv available to a later build stage or the final image? Is installing into the system interpreter via virtualenvs.create = false a supported production pattern, and what trade-offs does it carry for reproducibility and lock-file guarantees?