Should .poetry/plugins/poetry.lock be added to SCM when using [tool.poetry.requires-plugins]

[Spitfire1900]

I'm using poetry-dynamic-versioning on Poetry 2.1 using the [tool.poetry.requires-plugins] feature; should the .poetry/plugins/poetry.lock file be added to source control?

[cookesan]

I would not commit .poetry/plugins/poetry.lock.

The project input is the [tool.poetry.requires-plugins] section in pyproject.toml. In Poetry's current source, .poetry/plugins is the project plugin cache. Poetry writes .poetry/.gitignore with *, creates .poetry/plugins/poetry.lock while installing missing project plugins into that cache, and invalidates the cache when the plugin section, Poetry version, or Python version changes.

So I would commit the pyproject.toml plugin requirement and treat .poetry/ as generated local state. If you need reproducibility, pin the plugin constraint in requires-plugins; each environment can then rebuild its own plugin cache.