Skip to content

uv lock / uv sync fails: unsatisfiable extras (and libreyolo[all] can't be installed on Python ≥ 3.12) #989

Closed

Description

@gboeer

uv lock / uv sync fails: unsatisfiable extras (and libreyolo[all] can't be installed on Python ≥ 3.12)

Summary

On current dev (092ce18), uv can't resolve the project at all. Fixing the first error only exposes the next one. There are five separate causes in pyproject.toml. One of them also affects pip users: pip install "libreyolo[all]" can't succeed on Python ≥ 3.12.

Reproduce

uv lock --dry-run   # uv 0.11.8
Because libreyolo:dev depends on pytest>=9.0.2 and executorch==1.2.0 depends on pytest<9.0,
we can conclude that executorch==1.2.0 and libreyolo:dev are incompatible.
And because only the following versions of executorch are available:
    executorch<=1.2.0
    executorch>1.3
and libreyolo[executorch] depends on executorch>=1.2,<1.3 ...
your project's requirements are unsatisfiable.

Root causes

Each cause below was found by fixing the previous one and running the lock again.

# Conflict Why
1 dev group vs executorch executorch 1.2.0 lists pytest<9.0 as a runtime dependency, but the dev group requires pytest>=9.0.2.
2 paddle vs tflite / litert (and therefore all) paddle pins onnx>=1.14.0,<1.18 (for X2Paddle), but onnx2tf>=2.4.3 pins onnx==1.20.1 on Python ≥ 3.12. all includes both, so libreyolo[all] is unsatisfiable on Python ≥ 3.12 under pip too.
3 executorch vs tflite / litert onnx2tf>=2.4.3 pins pytest==9.0.2 at runtime, while executorch 1.2.0 requires pytest<9.0.
4 coreai on Python 3.10 coreai-torch>=0.4.1 requires Python ≥ 3.11, but the extra's marker is only sys_platform == 'darwin' and the project supports 3.10.
5 vla vs molmo2 and vs marigold lerobot==0.6.1 requires huggingface-hub>=1.6, but molmo2 pins transformers==4.57.1, which needs huggingface-hub<1.0. lerobot also requires accelerate>=1.14.0, but marigold pins accelerate==1.13.0.

Upgrading executorch doesn't help. Versions 1.3.1 and later drop the pytest pin but need torch>=2.12, and the pytorch-cu128 index stops at torch 2.11.

Proposed fix (tested: uv lock resolves)

 [dependency-groups]
 dev = [
-    "pytest>=9.0.2",
+    "pytest>=8.3",
 coreai = [
-    "coreai-torch>=0.4.1; sys_platform == 'darwin'",
+    "coreai-torch>=0.4.1; sys_platform == 'darwin' and python_version >= '3.11'",
 ]
 all = [
     ...
-    "libreyolo[paddle]",

(An alternative is to keep it as "libreyolo[paddle]; python_version < '3.12'".)

 [tool.uv]
 conflicts = [
     ...
+    [{ extra = "molmo2" }, { extra = "vla" }],
+    [{ extra = "marigold" }, { extra = "vla" }],
+    [{ extra = "paddle" }, { extra = "tflite" }],
+    [{ extra = "paddle" }, { extra = "litert" }],
+    [{ extra = "executorch" }, { extra = "tflite" }],
+    [{ extra = "executorch" }, { extra = "litert" }],
+    [{ extra = "executorch" }, { extra = "all" }],
 ]

With these changes the lock resolves executorch 1.2.0 with torch 2.11.0+cu128. pytest resolves to 8.4.2 alongside executorch and 9.0.2 alongside tflite.

Notes

  • No test uses a pytest-9-only API (subtests, RaisesGroup, etc.), so lowering the dev floor looks safe.
  • executorch and tflite/litert can't share an environment until executorch can move past 1.2 (blocked on a torch ≥ 2.12 CUDA index). Their tests have to run in separate environments.
  • No uv.lock is committed and nothing in CI runs uv lock, so this drifted unnoticed. A uv lock --check (or uv lock --dry-run) step in CI would catch the next one.

Activity

  1. EHxuban11 commented on Nov 2, 2026

    @EHxuban11
    Contributor

    This is embarassing 💀

  2. EHxuban11 commented on Nov 3, 2026

    @EHxuban11
    Contributor

    Hello @gboeer ,

    Fixed on both dev and latest release, and thank you for saving the library with this issue 🥇

    Just out of curiosity, do you use libreyolo at your work or is it in your free time?

  3. gboeer commented on Nov 4, 2026

    @gboeer
    ContributorAuthor

    11. Hello @gboeer ,
    Fixed on both dev and latest release, and thank you for saving the library with this issue 🥇
    Just out of curiosity, do you use libreyolo at your work or is it in your free time?

    No problem. Yes I'm currently trying out libreyolo at work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions