(🎁) Abillity to constrain transitive dependencies

[KotlinIsland]

• 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

In Gradle you can constrain transitive dependencies like this:

dependencies {
    implementation("org.apache.httpcomponents:httpclient")
    constraints {
        implementation("org.apache.httpcomponents:httpclient:4.5.3") {
            because("previous versions have a bug impacting this application")
        }
        implementation("commons-codec:commons-codec:1.11") {
            because("version 1.9 pulled from httpclient has bugs affecting this application")
        }
    }
}

In Poetry if I want to constrain a transitive dependency I have to specify the dependency as a direct dependency.

There are several advantages and motivations to specifying constraints over direct dependencies.

I would like to be able to specify constraints, maybe something like:

[tool.poetry.dependencies]
setuptools = { version: "60.2.0", constraint = true }

[KotlinIsland]

pip supports constraints https://pip.pypa.io/en/stable/cli/pip_install/#cmdoption-c

[KotlinIsland]

You can kinda get some transitive dependency functionality if you mark the dependency as optional and don't put it in an extra:

[tool.poetry.dependencies]
setuptools = { version: "60.2.0", optional = true }

Or maybe make a "constraints" group:

[tool.poetry.group.constraints]
optional = true

[tool.poetry.group.constraints.dependencies]
setuptools = "60.2.0"

But this isn't a full form solution.

[neersighted]

Because Python packaging is flat, Poetry has always taken the stance that if you care about a transient dependency at all (version, source, etc) it's now a top-level dependency, even if you don't import a module in that dependency directly.

I doubt we'll be revisiting that decision anytime soon, and for those that object, the pattern above with optional groups is supported/offers another path.

[KotlinIsland]

You can kinda get some transitive dependency functionality if you mark the dependency as optional and don't put it in an extra

the pattern above with optional groups is supported/offers another path.

The optional marker without an extra doesn't seem to make it optional in pip's eyes, see #7787

[jonapich]

Recently, a transitive dependency upgrade happened that created a conflict and even broke past setups that embraced "best practices" in pinning dependencies:

open-telemetry/opentelemetry-python#3382

This kind of bug means that the current working build stopped working, as well as most/all previous builds (for pip users).

On the same day, we also had problems with 2 top-level dependencies (boto3-stubs and click) that were marked as ^1.26.0 and ^8.1.2 respectively in our pyproject.toml file. Click's 8.1.4 has an issue with types vs mypy and boto3-stubs has a bunch of .postN transitive dependencies that appeared; one of them fails.

Since this is a CLI app and not a library that you're expected to import, we want to ensure to pin transitive dependencies for pip users so that this doesn't happen anymore in the future. A quick way to achieve this would be to use poetry export to generate a requirements.txt file and not include the pyproject.toml file with the package / not use poetry for publishing 😞

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