Poetry fails to parse required Python version

[vslotman]

• Poetry version: 1.5.1

• Python version: 3.10.6

• OS version and name: Windows 11

• pyproject.toml: https://gist.github.com/vslotman/84b56231d670544b7e3c6a4a89979750

• I am on the latest stable Poetry version, installed using a recommended method.

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

• I have consulted the FAQ and blog for any relevant entries or release notes.

• If an exception occurs when executing a command, I executed it again in debug mode (-vvv option) and have included the output below.

Issue

I try to install scipy in a clean poetry env. Somehow required python version is determined as >=3.13,<4.0.

• Current project's Python requirement: >=3.10,<4.0
• scipy Python requirement: <3.13,>=3.9
• Final python requirement: >=3.13,<4.0

Full poetry -vvv log here: https://gist.github.com/vslotman/2b44bd96bd4c0b2b1498baf233b745d1

$ poetry add scipy
Using version ^1.11.1 for scipy

Updating dependencies
Resolving dependencies...

The current project's Python requirement (>=3.10,<4.0) is not compatible with some of the required packages Python requirement:
  - scipy requires Python <3.13,>=3.9, so it will not be satisfied for Python >=3.13,<4.0

Because no versions of scipy match >1.11.1,<2.0.0
 and scipy (1.11.1) requires Python <3.13,>=3.9, scipy is forbidden.
So, because double-pendula depends on scipy (^1.11.1), version solving failed.

  • Check your dependencies Python requirement: The Python requirement can be specified via the `python` or `markers` properties

    For scipy, a possible solution would be to set the `python` property to ">=3.10,<3.13"

    https://python-poetry.org/docs/dependency-specification/#python-restricted-dependencies,
    https://python-poetry.org/docs/dependency-specification/#using-environment-markers

[dimbleby]

Not a bug.

Please read the error message, read the FAQ, close this issue

[vslotman]

A quick search reveals an incredible amount of bugreports stemming from the same confusion.
We could all save a lot of time and frustration if the error-message was a bit more clear.

[dimbleby]

sure, please submit a merge request making the error message a bit more clear

[manniche]

For further reference: numpy/numpy#24810

I'm not understanding how pointing to the documentation above answers the question "When I specify a constraint of Python as >=3.10,<4.0 and scipy specifies a constraint on Python as <3.13,>=3.9, I would expect the resolution of the constraint to be >=3.10, <3.13, then why is it >=3.13,<4.0?".

Reading the FAQ at https://python-poetry.org/docs/dependency-specification/#python-restricted-dependencies tells me that I can set dependency to use only a specific version of python. But if scipy is a transitive dependency, I have no direct control over setting the python version, so how is that going to help me here? I appreciate that dynamically computing constraints is a hard problem, and I would also like to say that I don't know how the error message could be clearer, since I don't understand how the documentation answers my questions on the cause of the - to me - weird version resolution of >=3.13, <4.0

[BeRT2me]

When it says

For numpy, a possible solution would be to set the `python` property to ">=3.10,<3.13"

It does NOT mean to change:

[tool.poetry.dependencies]
python = "^3.10"
numpy = "^1.26.0"

to

[tool.poetry.dependencies]
python = "^3.10,<3.13"
numpy = "^1.26.0"

---

It means to change it to:

[tool.poetry.dependencies]
python = "^3.10"
numpy = {version = "^1.26.0", python="^3.10,<3.13"}

Which resolves just fine!

If a future user is trying to use whatever outdated version of your package exists when 3.13 comes out, then it'll break because numpy won't get installed. But this allows them to try a newer version of numpy when using 3.13 (which may or may not work, up to them!) ... but more likely than not, you'll have a newer version by then, with a newer, compatible version of numpy pinned in a similar manner.

[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.