Use intersection rather than union for requires-python

[charliermarsh]

Summary

As-is, if you have a workspace with mixed requires-python requirements, resolution will never succeed, since we'll use the union as the requires-python bound (i.e., take the lowest value), and fail when we see the package that only supports some more narrow range.

This PR modifies the behavior to take the intersection (i.e., the highest value), so if you have one package that supports Python 3.12 and later, and another that supports Python 3.8 and later, we lock for Python 3.12. If you try to sync or run with Python 3.8, we raise an error, since the lockfile will be incompatible with that request.

Konsti has a write-up in #5594 that outlines what could be a longer-term strategy.

Closes #5578.

[charliermarsh]

We can warn here, if people feel strongly. I'm not sure that we should, though, since users will see it every time without any way to resolve it.

[codspeed-hq]

CodSpeed Performance Report

Merging #5644 will not alter performance

_{Comparing charlie/min-requires-python (1566081) with main (8d14a4c)}

Summary

✅ 13 untouched benchmarks

[konstin]

We should add a specific error message for this case that tells you how to run something on 3.8 with only bird-feeder.

[charliermarsh]

@konstin -- What's the recommended workflow? Can we even support it right now?

[konstin]

I'd say we check if the request version is in the union, but not in the intersection, and if so, recommend uv pip install -p 3.8 -e . <older-python-version-project>, which should work, i can test this after #5644 (comment)

[charliermarsh]

Yes, works.

[konstin]

Now i checked the right way and cargo run venv -p 3.8 && cargo run pip install -e packages/foo_lib/ indeed works.

[charliermarsh]

Will do separately.

[konstin]

Those codspeed numbers are dubious

[konstin]

I just tried the following project layout:

.
├── packages
│   ├── bar
│   │   ├── pyproject.toml
│   │   └── src
│   │       └── bar
│   │           └── __init__.py
│   └── foo_lib
│       ├── pyproject.toml
│       └── src
│           └── foo_lib
│               └── __init__.py
├── pyproject.toml
├── README.md
└── uv.lock

bar:

[project]
name = "bar"
version = "0.1.0"
requires-python = ">=3.12"
dependencies = []

[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"

foo_lib:

[project]
name = "foo-lib"
version = "0.1.0"
requires-python = ">=3.8"
dependencies = []

[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"

When trying to uv lock, i get:

Using Python 3.12.1
  × No solution found when resolving dependencies:
  ╰─▶ Because the requested Python version (>=3.8) does not satisfy Python>=3.12 and bar==0.1.0
      depends on Python>=3.12, we can conclude that bar==0.1.0 cannot be used.
      And because only bar==0.1.0 is available and you require bar, we can conclude that the
      requirements are unsatisfiable.

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

It seems that the PR currently forces the same requires-python across the workspace.

[charliermarsh]

You must be running from main? It works fine for me on this PR, I just replicated it.

[charliermarsh]

version = 1
requires-python = ">=3.12"

[[distribution]]
name = "bar"
version = "0.1.0"
source = { editable = "packages/bar" }

[[distribution]]
name = "foo-lib"
version = "0.1.0"
source = { editable = "packages/foo_lib" }

[[distribution]]
name = "root"
version = "0.1.0"
source = { editable = "." }

[konstin]

Right branch but it was using uv lock, not cargo run lock 😶 With this branch it actually works

[charliermarsh]

Haha yeah. That's the exact problem this was designed to fix 😂