Cannot require exact python version

[uwu-420]

Checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pixi, using pixi --version.

Reproducible example

• Create a new project pixi init foo --format pyproject and cd into it
• In pyproject.toml under [project] change the requires-python to e.g. "==3.13.2"
• pixi install results in the following error

Error:
  × failed to solve the pypi requirements of 'default' 'osx-arm64'
  ├─▶ failed to resolve pypi dependencies
  ╰─▶ Because the requested Python version (==3.13.*) does not satisfy Python==3.13.2 and foo==0.1.0 depends on Python==3.13.2, we can conclude that foo==0.1.0 cannot be used.
      And because only foo==0.1.0 is available and you require foo, we can conclude that your requirements are unsatisfiable.

      hint: The `requires-python` value (==3.13.*) includes Python versions that are not supported by your dependencies (e.g., foo==0.1.0 only supports ==3.13.2). Consider using a more restrictive `requires-python` value (like ==3.13.2).

Issue description

Currently, seems like pixi cannot properly handle requiring an exact python version like major.minor.patch

Expected behavior

I would expect it to not error and exactly use the specified version when creating the env.

[tdejager]

You are correct I think I've encountered this before!

[tdejager]

I'm never sure what behavior we would want here, uv says it is only respecting the lower bound on the requires-python. https://docs.astral.sh/uv/reference/resolver-internals/#requires-python. However, as we can see during a build if a version is very narrow this is taken into account.

We are converting the resolved record like 3.12.3 to 3.12.*. A problem with this is that we are looking at the resolved record and not at the input spec. However, as requires-python serves like a double purpose. I guess for pyproject.toml taking over the requires-python verbatim makes sense. Does it also makes sense for pixi.toml?