poetry: Cannot install Apache Airflow due to ambiguous constraint

When you talk about poetry “supporting constraints” - I think you mean: things that are like requirements eg “foo>=1.2”, but which don’t actually require the named package to be installed?

presumably the use case for such things would be for transitive dependencies where you don’t want to specify an explicit dependency, but if the solver does encounter that package then you want to guide it towards (or away from) some particular version?

I’ve seen requests for similar, but don’t recall anything spelling out this particular approach.

Feel free to raise a feature request where folk can figure out whether this is a good idea, or a duplicate, or neither, or both.

Fix for airflow provider packages in https://github.com/apache/airflow/pull/27727

Just noting that indeed poetry does make a mess of prefix matching on == constraints: this code

#!/usr/bin/env python3

from poetry.core.constraints.version.version import Version
from poetry.core.constraints.version import parse_constraint

constraint = parse_constraint("==1.1.*")
version = Version.parse("1.1a1")
allowed = constraint.allows(version)
print(f"{allowed=}")

says allowed=False which certainly disagrees with one of the examples in PEP440.

So while - at least according to my reading - the problem in this particular issue is the airflow constraint rather than the poetry handling of it, we’re certainly very adjacent to a poetry bug

A new one would be lovely, thanks

Yep. That’s what I have in my PR.

https://peps.python.org/pep-0440/#summary-of-permitted-suffixes-and-relative-ordering

Within a numeric release (1.0, 2.7.3), the following suffixes are permitted and MUST be ordered as shown:

.devN, aN, bN, rcN, <no suffix>, .postN

Each of those (alpha, beta, etc.) are completely separate naming space.

this is not true. Their order is well defined by PEP440 and a regular >= starting at the earliest should meet your need.

I think ==1.3.0.* achieves what you want per PEP 440 (though I suspect that poetry will make a mess of that). Also >=1.3.0rc1 should work (and I think poetry will get that right).

So far as I can tell PEP 440 simply doesn’t allow >=1.3.0.* and so it’s presumably more or less arbitrary whether pip or poetry happens to do what you want

@potiuk I don’t see any justification for >=1.3.0.* in https://peps.python.org/pep-0440/#inclusive-ordered-comparison.

==1.3.0.* would be allowed per the previous section (and quite possibly mis-handled by poetry) but the >= operator requires an actual version identifier - which 1.3.0.* is not.

@r-richmond that still requires that “the available version satisfies the version specifier”. poetry has done its best with the malformed version specifier, interpreting it as >=1.3.0, but no available version does satisfy that.

I’m at risk of being out of my depth here but the following statement

not a bug, because the requirement is >=1.3.0 and the highest available version is 1.3.0rc1 - which is strictly less than 1.3.0

Appears to be at odds with the spec defined in pep 440 Specifically the last portion of this sentence

Pre-releases of any kind, including developmental releases, are implicitly excluded from all version specifiers, unless they are already present on the system, explicitly requested by the user, or if the only available version that satisfies the version specifier is a pre-release.

not a bug, because the requirement is >=1.3.0 and the highest available version is 1.3.0rc1 - which is strictly less than 1.3.0

(possibly also duplicate #4405, though I’ve not read the whole of that issue)