Should .poetry/plugins/poetry.lock be added to SCM when using [tool.poetry.requires-plugins]
#10390
-
|
I'm using poetry-dynamic-versioning on Poetry 2.1 using the |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments
-
|
I would not commit The project input is the So I would commit the |
Beta Was this translation helpful? Give feedback.
-
|
Adding to @cookesan — two details worth making explicit: Auto- Pinning for CI reproducibility: pin the exact plugin version directly in [tool.poetry.requires-plugins]
poetry-dynamic-versioning = "==1.4.1" # exact pin for CI stabilityWith an exact pin, Poetry should install the same plugin version on fresh environments without committing the plugin lockfile The plugin cache under A compatible-range constraint, for example |
Beta Was this translation helpful? Give feedback.
-
|
Follow up question, should poetry plugins be included in a projects' poetry.lock? This is a architectural question, it doesn't do that today. |
Beta Was this translation helpful? Give feedback.
Adding to @cookesan — two details worth making explicit:
Auto-
.gitignore: Poetry writes.poetry/.gitignorewith*when it creates the project plugin cache, so.poetry/plugins/poetry.lockis excluded from version control automatically. You do not need a manual.gitignoreentry for itPinning for CI reproducibility: pin the exact plugin version directly in
pyproject.toml:With an exact pin, Poetry should install the same plugin version on fresh environments without committing the plugin lockfile
The plugin cache under
.poetry/pluginsis project-local and regenerated automatically when Poetry …