Wrong `python_full_version` in `uv.lock`

[TheRealBecks]

I have the following pyproject.toml:

[project]
name = "lightning"
description = "Ansible Network Automation for Cisco IOS, Cisco NX-OS and Arista EOS"
readme = "README.md"
version = "1.0.0"
requires-python = "==3.12"
dependencies = [
  "ansible",
  "ansible-core",
  "ansible-navigator",
  "ansible-pylibssh",
  "hvac",
  "jmespath",
  "netaddr",
  "paramiko",
  "pyavd[ansible]",
]

[project.optional-dependencies]
dev = [
  "icecream",
  "ruff==0.6.2",
]

requires-python is hard coded to version ==3.12.

With uv sync (without any extras to be installed) a uv.lock has been created with the following data in the first few lines:

version = 1
requires-python = "==3.12"
resolution-markers = [
    "python_full_version < '3.13'",
    "python_full_version >= '3.13'",
]

The second line of python_full_version looks wrong as it declares the version to be >= '3.13' while the first one says < '3.13'.

I used uv in version 0.3.5 on Opensuse Tumbleweed Linux.

[TheRealBecks]

I also tried version 0.4.0, but that does not change the python_full_version.

[charliermarsh]

resolution-markers is effectively internal bookkeeping for the resolver. Are you seeing an incorrect resolution?

[zanieb]

Generally it's expected for these markers to be disjoint. See the documentation on forking at https://docs.astral.sh/uv/reference/resolver-internals/#forking

[TheRealBecks]

I requested Python 3.12 (12!), but the resolution-markers are:

1. < '3.13' --> That's correct for version 3.12
2. >= '3.13' --> That's wrong for version 3.12. I expected >= '3.12'

So I think that's wrong? 😀

[charliermarsh]

That's still ok! It's internal state that represents how we resolved the dependencies. It doesn't effect the outcome when you run uv sync or similar.

[TheRealBecks]

Okay, if you say so then this issue/question can be closed! 😀

Thanks a lot for the fast response!

[zanieb]

Related #6150