Bug? Python version-dependent constraints are applied across all Python versions

[jherland]

Consider a project that supports a wide range of Python version, and with a single dependency, like this:

[tool.poetry.dependencies]
python = ">=3.7.2"
setuptools = ">=68.0.0"

setuptools removes support for Python 3.7 in version 68.1.0, and Poetry handles this correctly: When I am using Python 3.7 on this project, Poetry correctly installs 68.0.0 (the last version that supports Python 3.7).

However, when I am using any newer Python version (>=3.8) on this project, Poetry still installs setuptools 68.0.0 (even though the the latest version for Python >=3.8 is 69.0.3).

This seems wrong to me, as I would expect Poetry to install 68.0.0 for Python 3.7 and 69.0.3 for all newer Python versions.

I have found a way to "convince" Poetry to follow my expectations:

[tool.poetry.dependencies]
python = ">=3.7.2"
setuptools = [
    # v68.1.0 drops support for Python v3.7:
    {version = ">=68.0.0", python = ">=3.8"},
    {version = ">=68.0.0,<68.1.0", python = "<3.8"},
]

I consider this to be an ugly workaround as it repeats setuptools' own limitation in my pyproject.toml (something that I should not have to do, as this can be deduced from setuptools' own metadata). Still, this somehow convinces Poetry to follow my expectations: install 68.0.0 for Python 3.7 and 69.0.3 for all newer Python versions.

Is this a bug in Poetry, or have I misunderstood something in my expectations of what Poetry should do here?

(I've created a minimal example at https://github.com/jherland/poetry_overspecify_deps_demo to demonstrate this issue.)

[jherland]

(BTW, this is reproducible both in Poetry v1.6.1 and v1.7.1)

[radoering]

Not a bug, but rather a shortcoming or missing feature, which is missing because of its complexity and performance overhead. Poetry does not split up a dependency by itself. If you specify setuptools = ">=68.0.0", Poetry will try to find one version of setuptools that is suitable for all supported Python versions.

[jherland]

Understood, thank you. This is a known shortcoming, so there's no point in opening a new issue about it?

[radoering]

No. I don't expect this to change in the near future unless someone comes up with PR that provides a maintainable solution, which does not result in a too bad performance overhead.