Lock Python version itself

[tmshn]

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have searched the documentation and believe that my question is not covered.

Feature Request

Poetry is not only good at developing libraries, but also good at application, which requires careful version lock of depending packages.

However, Poetry doesn't lock Python version. This might led to version mismatch between developers. Say we have constraint ^3.7, some member might use 3.7.6 while others might 3.8.1.

IMO, we should lock Python version too to have better reproducibility of environment.

(Note: this is somewhat related to #2558)

[finswimmer]

Hello @tmshn,

poetry doesn't only lock the dependencies for the currently used python version. When it resolves the dependencies, it's looking for package versions that matches every python version, to which the project is compatible and chooses this one. So it doesn't matter, if one developer will use python 3.7 or python 3.8. Unless you haven't specify explicit to use different package version for this python version the same package version gets installed.

If it's absolutely necessary that the same python version is used everywhere you have to set a fix value in your pyproject.toml.

fin swimmer

[tmshn]

Hi @finswimmer, thank you for the very quick reply!

Let me clarify this point more to understand how Poetry works:

it's looking for package versions that matches every python version, to which the project is compatible and chooses this one

Assume we have constraint python = "^3.7" and add some package e.g. poetry add foo, Poetry tries to find the best version of foo which is compatible for all Python 3.7, 3.8, and so on, right? How does it check if it is compatible for say Python 3.10?

---

I agree with you that explicit version specification in pyproject.toml is a good practice, but feel the DX is not well aligned with how package versions are handled. In application developmen, poetry.lock plays mandatory role so that every developers (and usually production docker image) can have same versions of packages.

So you mean, we should use poetry.lock for package version lock, while using pyproject.toml for Python version lock?

[tmshn]

(Note: I don't meant to blame how Poetry works; just want to know its design choice and rationale behind that)

[finswimmer]

Assume we have constraint python = "^3.7" and add some package e.g. poetry add foo, Poetry tries to find the best version of foo which is compatible for all Python 3.7, 3.8, and so on, right?

Correct.

How does it check if it is compatible for say Python 3.10?

It just looks at the constraints given by the package. If a package claim to be compatible for python>=3.6 it is compatible to python 3.10 for poetry.

So you mean, we should use poetry.lock for package version lock

Definitely.

while using pyproject.toml for Python version lock

A python version lock should only be necessary if you want to rely on certain features of these version, like e.g. f-string. If this is mandatory for you, than yes.

[tmshn]

Just summary:

	Package versioning	Python versioning
Coarse specification	use pyproject.toml	use pyproject.toml
Strict lock	use poetry.lock	usually not necessary, but use pyproject.toml otherwise

[tmshn]

I understand this is the design choice rather than just happened as a result of implementation, so closing.
Thank you for the explanation! @finswimmer

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.