Edge case error with calculated constrains

[pedro-psb]

I've just hit a very unlike edge case that can happen if a package skips a Y release (here).

The following scenario apparently doesnt make sense, unless you see that there isnt any 3.45.* in the PyGObject release history.

# requirements.txt
PyGObject>=3.40,<3.46

# generated constrain.txt
pygobject~=3.45

# error
The conflict is caused by:
  pulp-rpm 3.18.22.dev0 depends on PyGObject<3.46 and >=3.40
  The user requested (constraint) pygobject~=3.45

It doesnt feel like the calc_constrain code should validate the version, but maybe we can introduce a special comment syntax to deal with those edge cases, like:

# requirements.txt
PyGObject>=3.40,<3.46  # skip: 3.45

# generated constrain.txt (fixed)
pygobject~=3.44

[mdellweg]

In that case we just don't declare <3.46 in the first place. The whole idea of having an upper bound is that even if 3.45.0 is released tomorrow it cannot break us without a PR.

[pedro-psb]

Closing because pinning to the maximum known valid release lower than what was specified before (<3.45 instead of <3.46, in this specific case) is a reasonable solution for this edge case.

[mdellweg]

Closing because pinning to the maximum known valid release lower than what was specified before (<3.45 instead of <3.46, in this specific case) is a reasonable solution for this edge case.

Yeah, just that I would not call this an edge case, but exactly the very reason this check was added. We want to know that the newly allowed version is installable and compatible.

[pedro-psb]

Fair. I was really overlooking it's purpose, thanks for pointing out.