Make < exclusive for non-prerelease markers

[charliermarsh]

Summary

Even when pre-releases are "allowed", per PEP 440, pydantic<2.0.0 should not include pre-releases. This PR modifies the specifier translation to treat pydantic<2.0.0 as pydantic<2.0.0.min0, where min is an internal-only version segment that's invisible to users.

Closes #1641.

[charliermarsh]

I think (1) and (2) could be "solved" by only applying this logic when pre-releases are already enabled for a given package.

[mitsuhiko]

What if there is a PreRelease { kind: PreReleaseKind::PreReleaseHack, number: 0}`` (find a better name) that behaves as a perfect match to a0but is special cased in rendering. It would show up as2.0.0rather than2.0.0.a0` maybe with an additional indicator about how it considers prerelease versions.

          attrs>20.3.0,<21.2.0 (including pre) cannot be used.
          And because you require attrs>20.3.0,<21.2.0 (including pre), we can conclude that the

[charliermarsh]

@mitsuhiko - That's also interesting, it could work, though I still wonder if including the pre-release info is useful in cases in which pre-releases are entirely omitted.

[charliermarsh]

\cc @Czaki who brought up the idea on GitHub.

[Czaki]

Hm. Why is pre-release even triggered by upper constraint? All time when I would like to test pre-release of some package or see such case, the lower bound is used. But my experience may be not so big.

I wil ltry to check code later.

[dimbleby]

.dev0 comes before .a0 anyway

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

[Czaki]

.dev0 comes before .a0 anyway

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

And cannot by uploaded to pypi.

[dimbleby]

And cannot by uploaded to pypi.

alas the world is complicated: pypi is not the only source of distributions

either way, if the intention is to make <2 exclude pre-releases, might just as well exclude .dev releases too.

another way might be to represent this as something like <=1.infinity, which might work better as being something that you could easily recognise when writing it back: no-one could actually write that down, whereas if what you have is <2.0.0.dev0 you cannot be certain that this was not the original constraint all along

[charliermarsh]

This makes sense, I'll likely change to dev.

[mitsuhiko]

I would just honestly really represent it as something that is not parsable. The PreReleaseHack can basically act as the .infinity proposal. It can only be expressed by the resolver internally and is otherwise never valid input.

[konstin]

Have you checked that this also applies to 2.0.0.a0.dev0?

[charliermarsh]

I honestly don't mind representing this (even to users) as <2.0.0.dev. If they see this, then they opted-in to pre-release handling (it doesn't get included otherwise).

[charliermarsh]

Okay, now using @mitsuhiko's suggested approach which I will begrudgingly admit is a better solution :)

Now handles all cases correctly, even:

apache-airflow[otel]
opentelemetry-exporter-prometheus<0.44

From the brilliant @notatallshaw (thank you for that).

[BurntSushi]

This LGTM, but you'll definitely need to bump the simple cache version in order to invalidate extant caches due to the change in representation of Version. (Apologies if you did that and I missed it.)

[BurntSushi]

Sweet