Make the uv environment build on macOS and Linux, and let YORU pick its compute device

[rysk-t]

uv sync only ever worked on Windows. tool.uv.environments pinned the lockfile to sys_platform == 'win32', so resolution aborted on macOS and on a Linux CUDA host before a single package was considered — and behind that pin sat five more portability defects, each visible only once the previous one was fixed.

Separately, ultralytics resolves an unnamed device CUDA → CPU and never auto-selects MPS. Since YORU had no device plumbing at all, every Apple Silicon user was silently training and inferring on the CPU.

Both are fixed. There is now CI, which would have caught the first one.

Packaging

• Drop the win32 environment pin; fork the resolution over win32/linux/darwin so one lockfile serves Windows+CUDA, Linux+CUDA and macOS+MPS.
• Take torch/torchvision from the cu124 index on Windows and Linux only, and from PyPI (the build carrying Metal support) on macOS.
• Raise requires-python to >=3.10. dearpygui 1.11.1 ships macOS arm64 wheels for cp310+ only, and 3.9 is EOL.
• Bound numpy to <2. opencv-python 4.10.0.82 is built against the numpy 1.x ABI; on 3.10+ an unbounded numpy resolved to 2.x and broke import cv2.
• Mark pywin32 win32-only (it is never imported anywhere in the source), drop pyopengl-accelerate (no arm64 wheel, sdist fails to cythonize) and the pyqt5-qt5==5.15.2 override (that version has no arm64 wheel).
• Tell hatchling the package directory is yoru — it could not infer that from the distribution name yoru_uv, so uv sync failed to build the project on every platform once the lock was regenerated.
• Relax setuptools<70 to <81. The real constraint is pkg_resources, removed in setuptools 81 and still imported by eel, which is what YORU.yml already documented.

The committed lock had drifted to a different manifest entirely (root package yoru/0.1.0, ultralytics==8.2.52), so uv sync --locked failed everywhere and plain uv sync silently re-locked — nobody was installing the pinned versions. Regenerated, and CI now guards it.

Device selection

New yoru/libs/device.py resolves CUDA → MPS → CPU, honours a YORU_DEVICE override, and degrades with a logged warning when a device is unavailable. Both training scripts gained --device, the training GUI gained a selector with a resolved-device readout, and the inference wrappers now name the device on every predict call.

torchvision's detection heads needed care: before 0.29 they mis-train on MPS. Measured here on Faster R-CNN, same dataset, one epoch:

torchvision	device	Avg Loss
0.26.0	mps	inf
0.29.0	mps	0.5047 / 0.4859 / 0.4218
0.29.0	cpu	0.4883 / 0.4688 / 0.4861

macOS is therefore pinned to torchvision 0.29+, and _resolve_device checks the installed version rather than refusing MPS outright, since the conda environment can still carry an older build.

Also fixed

• yoru/testing.py was a stub that wrote a b"dummy" checkpoint, so both smoke tests passed in 0.19 s and proved nothing. They now drive the real create_yaml_train → train_ultralytics → load_yolo_model round trip.
• tests/test_cuda.py hard-asserted torch.cuda.is_available(), making the suite red on any machine without an NVIDIA GPU. It now skips.
• yoru/app.py's config-creator launcher used subprocess.CREATE_NEW_CONSOLE, which does not exist off Windows, and was the only GUI not going through the portable _launch_gui helper.
• yoru/libs/detection.py imported dearpygui but never used it, making the detection module need a GUI toolkit for nothing.
• The vendored YOLOv5 gated MPS on the deprecated torch.has_mps.

Documentation

The uv route installs everything a Python environment can hold, so what was left
undocumented were the pieces it cannot install. README gains a Prerequisites
section covering them:

• A Chromium browser. The launcher is served by Eel, which uses its chrome
  mode, so Chrome or Chromium has to be findable (the App Paths\chrome.exe
  registry key on Windows, Google Chrome.app / Chromium.app / mdfind on
  macOS, four binary names on PATH on Linux). Edge is Chromium-based but
  registers as msedge.exe and is not found; Safari is unsupported by Eel. Only
  the launcher needs it -- every other GUI is a native window.
• An NVIDIA driver. The wheels carry their own CUDA runtime, so the CUDA
  toolkit is optional; what is required is a driver supporting CUDA 12.x
  (527.41+ on Windows, 525.60.13+ on Linux).
• macOS. Apple Silicon and macOS 14+ only, xcode-select --install before
  uv sync because imgui and gevent have no arm64 wheels and are compiled,
  and the Camera / Input Monitoring / Screen Recording prompts that appear on
  first use.

The uv section is promoted out of the conda quick install, gains the uv
installation commands themselves, and says to run from the repository root,
since the launcher resolves web/ and config/ relative to the working
directory. docs/install.md is restructured around the same prerequisites with
both routes side by side, keeping the existing conda steps.

Also recorded: YORU_DEVICE does not reach YOLOv5 inference, which loads
through torch.hub and picks CUDA or CPU on its own.

Compatibility

Windows and Linux resolve exactly as before — torch 2.6.0+cu124, torchvision 0.21.0+cu124, setuptools 69.5.1. Only the macOS fork moves.

The macOS floor is now 14 (Sonoma, Sept 2023), because torchvision 0.29 requires torch 2.14 whose macOS wheels target macosx_14_0. Reverting that means giving up MPS training for the torchvision backends; YOLO training on MPS is unaffected either way.

Verification

CI is green on ubuntu / windows / macos. On macOS 26.5.2, Apple M5 (arm64), uv 0.11.14:

• uv sync --locked → Python 3.10.19, torch 2.14.0, torchvision 0.29.0, ultralytics 8.3.222, opencv 4.10.0, numpy 1.24.4, dearpygui 1.11.1
• pytest → 79 passed, 7 skipped
• Training via the exact argv train_GUI builds, --device auto → Device: Apple MPS; 30 epochs on 400/100 frames of test_data reached mAP50 0.974 / mAP50-95 0.692
• Inference through load_yolo_model over the test video: MPS and CPU return identical detections
• Both smoke tests exercise real training and inference

The GitHub runners have no NVIDIA GPU, so a green Windows leg only proves the environment resolves, installs and imports. That gap is now closed on a real Windows box — Windows 11, RTX 4070 SUPER, uv 0.8.19:

• uv lock --check clean, uv sync --locked → uv-managed CPython 3.10.18, torch 2.6.0+cu124, torchvision 0.21.0+cu124, ultralytics 8.3.229
• torch.cuda.is_available() → True; resolve_device("auto") → cuda
• uv run pytest → 83 passed, 3 skipped
• Both smoke tests run end to end against test_data/labeled_frames: training (64 train / 16 val, 1 epoch, CPU) writes best.pt in 14 s, and inference through load_yolo_model consumes it
• Full round trip on CUDA: 30 epochs → mAP50 0.923 / mAP50-95 0.576, and inference over 20 real frames returns 24 detections (conf 0.27-0.98) across both classes

Still unexercised: the GUI device selector was import-checked only, on both platforms — no interactive run — and no closed-loop hardware (NI-DAQ / Arduino) was attached.