Support for strict release dependency resolution with PEP621/PEP735 style dependency declaration

[armingerten]

Issue Kind

Other

Description

As stated on https://python-poetry.org/docs/dependency-specification/#handling-of-pre-releases :

Per default, Poetry will prefer stable releases and only choose a pre-release if no stable release satisfies a version constraint. In some cases, this may result in a solution containing pre-releases even if another solution without pre-releases exists. If you want to disallow pre-releases for a specific dependency, you can set allow-prereleases to false. In this case, dependency resolution will fail if there is no solution without choosing a pre-release.

This seems to be compliant with Python's specification for handling of pre releases.

Starting with Poetry 2.2.0, dependencies and dependency groups can be declared using project.dependencies/ project.dependency-groups. When doing so, Poetry will choose pre-releases if no stable release satisfies a version constraint by default.

Is there any way to instruct Poetry to excluding pre-releases for all version specifiers (reporting an error or warning if a pre-release is already installed locally, or if a pre-release is the only way to satisfy a particular specifier) without falling back to tool.poetry.dependencies?
A global configuration (instead of a per-package configuration) would also suffice.

Impact

This is not a show stopper. However, we would like to stick to Python's packaging specification as close as we can and use as little proprietary configuration items in pyproject.tomls as possible.

Workarounds

The only known workaround is to fall back to tool.poetry.dependencies.

[dimbleby]

poetry cannot unilaterally invent new configuration in the PEP621 part of pyproject.toml

if you think this is something that belongs in the project definition, suggest that https://discuss.python.org/c/packaging/14 would be a good place to start.

[armingerten]

poetry cannot unilaterally invent new configuration in the PEP621 part of pyproject.toml

Of course! I opened this issue because maybe I overlooked something in the PEP621 (or maybe the PEP508 specification) how this can be controlled per dependency.

In terms of configuration the behavior, I could also imagine how this behavior could be controlled by providing a --allow-prereleases=false or --exclude-prereleases option for commands like poetry lock or poetry upgdate.

[dimbleby]

if you can point at a part of a spec that would meet your need then go for it.

But I think what you are asking for is: tool-specific configuration magically implemented in a non-tool-specific way