Method for enforcing a minimum version of Poetry

[PetterS]

Poetry 1.1 is not compatible with 1.0, so we need to enforce Poetry version for our development team one way or another.

There is this Stack Overflow question: https://stackoverflow.com/questions/64003868/how-to-enforce-a-minimum-python-poetry-version which currently is unanswered.

Is there a way of specifying a version of Poetry in pyproject.toml that will fail if the executing version of poetry does not match? What effect does [build-system] requires have?

[abn]

At present, poetry does not enforce a version required as in theory it is not necessary per say at the moment as it is the lock file that is not forwards compatible.

root@cc2fc2786035:/foobar# cat poetry.lock | grep lock-version
lock-version = "1.1"
root@cc2fc2786035:/foobar# pip install -q --force poetry==1.0.10
root@cc2fc2786035:/foobar# poetry install
The lock file might not be compatible with the current version of Poetry.
Upgrade Poetry to ensure the lock file is read properly or, alternatively, regenerate the lock file with the `poetry lock` command.
...

That said, the lock version is the closest thing we have at the moment. As you can see above, lock files generated since 1.0.10 if add and verify lock-version metadata in the poetry.lock file. Version 1.1.0 onwards the lock-version is 1.1 (note that this is not tied to poetry version, but to the lock file format).

Lock file generated using poetry>=1.1.0 will raise a warning if used with poetry==1.0.10. For now, in cases where poetry version used to generate the lock file needs to be enforced, you could possible verify this by checking if poetry lock --no-update generates a diff.

As for build-system.requires, this does not have any bearing on how poetry operates as it is relevant only to PEP 517 scenarios. This informaiton is used when a PEP 517 front-end builds the project and needs to know what dependencies to install when doing so. For example, this is used when you do pip install /path/to/poetry/project. And this is now expecte to use poetry-core and not poetry.

[PetterS]

Right, it is the format of the lock file and possibly the virtualenv that is the issue.

But alright, it makes upgrading from 1.0 to 1.1 harder but not impossible.

I have found that if the system version of poetry is 1.0 and 1.1 is added as a dep into the pyproject.toml, the newer version will be used for the project from that point on. That feels a bit nonstandard though.

[abn]

I have found that if the system version of poetry is 1.0 and 1.1 is added as a dep into the pyproject.toml, the newer version will be used for the project from that point on. That feels a bit nonstandard though.

Probably not a good idea if you are adding it as a dependnecy as this will affect your dependency graph.

[PetterS]

Probably not a good idea if you are adding it as a dependnecy as this will affect your dependency graph.

I agree. It would be a dev dependency and for an internal project but I am not looking for creative solutions here. :-)

[kimmoahola]

Would be great to make somehow sure that every team member has recent enough poetry.

In future poetry may add (more) non-backwords compatible features.

Is it possible run bash in https://python-poetry.org/docs/pyproject/#scripts ?

And if there would be some "preinstall" hooks (like in Node's package.json) then it would be possible to create a simple bash script to do the version checking.

Or maybe just add something like

[tool.poetry.checks]
poetry-version="^1.1"

to pyproject.toml

[cpvandehey]

Adding a "plus 1" to this problem. The Node world seems to have solved this problem by specifying node versions with the engineStrict feature.