`requires-python` value too low for instant install.

[MathijsdeBoer]

Just pulling the project and getting uv to prepare an environment for me, I received the following error on package solving:

(napari-nninteractive) PS D:\PythonProjects\napari-nninteractive> uv run napari -w napari-nninteractive
  x No solution found when resolving dependencies for split (python_full_version < '3.11'):
  `-> Because the requested Python version (>=3.10) does not satisfy Python>=3.11 and blosc2>=3.0.0 depends on Python>=3.11, we can conclude that blosc2>=3.0.0 cannot be used.
      And because only the following versions of blosc2 are available:
          blosc2<3.0.0b4
      we can conclude that blosc2>=3.0.0b4 cannot be used.
      And because acvl-utils>=0.2.3 depends on blosc2>=3.0.0b4 and only the following versions of acvl-utils are available:
          acvl-utils<=0.2.3
          acvl-utils==0.2.4
          acvl-utils==0.2.5
      we can conclude that acvl-utils>=0.2.3 cannot be used.
      And because nninteractive==1.0.1 depends on acvl-utils>=0.2.3 and only nninteractive==1.0.1 is available, we can conclude that nninteractive==1.0.1 cannot be used.
      And because your project depends on nninteractive==1.0.1 and your project requires napari-nninteractive[testing], we can conclude that your project's requirements are unsatisfiable.

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

      hint: `blosc2` was requested with a pre-release marker (e.g., blosc2>=3.0.0b4,<3.0.0), but pre-releases weren't enabled (try: `--prerelease=allow`)

The fix was to manually change the requires-python value in pyproject.toml from ">=3.10" to ">=3.11" and rerunning uv run napari.

[FabianIsensee]

This seems to be related to uv. We cannot reproduce it with pip, tested across Ubuntu and Windows and using python3.10
Best,
Fabian

[MathijsdeBoer]

Looks like blosc2 switched requires-python from 3.10 to 3.11 when the version switched from 3.0.0b4 (the dependency of acvl-utils) to the next available tag, 3.0.0rc1, as well as the subsequent full release of 3.0.0.

If I'm not mistaken, given a range of possible python versions (in this case >=3.10), uv tries to solve for all possible combinations.
Because 3.0.0b4 is a pre-release version, uv seems to prefer to not use it during solving.
Because the only version(s) of blosc2 that are available, and that satisfy >=3.0.0, all have requires-python >=3.11, uv is not able to generate a valid lock file for 3.10 environments.

Presumably, pip does not follow nearly such a stringent locking scheme, and will just grab whatever on good faith.