Dev the local package in each GPU test environment

[ChrisRackauckas-Claude]

Please ignore this PR until it has been reviewed by @ChrisRackauckas.

The bug

Every lib/*/test/gpu/Project.toml lists the sublibrary under test in [deps], but most had no matching [sources] entry. So Pkg resolved the package being tested from the General registry rather than from the working tree.

For lib/OrdinaryDiffEqCore/test/gpu that is fatal. The registry's newest OrdinaryDiffEqCore is 4.8.0; the working tree is at 4.11.1; and OrdinaryDiffEqTsit5 — which does arrive by path, through the umbrella's [sources] — has compat OrdinaryDiffEqCore = "4.10":

ERROR: LoadError: Unsatisfiable requirements detected for package OrdinaryDiffEqCore [bbf590c4]:
 ├─possible versions are: 1.0.0 - 4.8.0 or uninstalled
 ├─restricted to versions 4.8.0 - 5 by OrdinaryDiffEq       → leaving only 4.8.0
 └─restricted to versions 4.10.0 - 4 by OrdinaryDiffEqTsit5 → no versions left

A source entry is needed on the gpu environment itself. [sources] is only read from the active project, and a direct dependency of the active project with no source is taken from the registry regardless of what any dependency's [sources] says. That is exactly why OrdinaryDiffEqTsit5 (not a direct dep of the gpu env) resolves to a path while OrdinaryDiffEqCore (a direct dep) does not.

The quieter half

The six environments that did resolve were resolving the package under test from the registry — running the GPU suite against the last release instead of the branch. Green, and meaningless. That is arguably the worse failure, since it produced no signal at all.

The change

One [sources.<self>] entry per affected gpu environment. 7 files, +21 lines, no code.

Verification

I resolved every gpu environment before and after (scratch copy of each Project.toml at identical directory depth so the relative paths still apply), recording where the package under test and OrdinaryDiffEqCore actually come from:

gpu env	before	after
OrdinaryDiffEqCore	RESOLVE FAILED	self=LOCAL Core=LOCAL
OrdinaryDiffEqBDF	self=REGISTRY Core=REGISTRY	self=LOCAL Core=LOCAL
OrdinaryDiffEqRKIP	self=REGISTRY Core=REGISTRY	self=LOCAL Core=LOCAL
OrdinaryDiffEqLinear	self=REGISTRY Core=LOCAL	self=LOCAL Core=LOCAL
OrdinaryDiffEqLowStorageRK	self=REGISTRY Core=LOCAL	self=LOCAL Core=LOCAL
OrdinaryDiffEqRosenbrock	self=REGISTRY Core=LOCAL	self=LOCAL Core=LOCAL
OrdinaryDiffEqStabilizedRK	self=REGISTRY Core=LOCAL	self=LOCAL Core=LOCAL
OrdinaryDiffEqDefault	self=LOCAL Core=LOCAL	unchanged
StochasticDiffEq	self=absent Core=absent	unchanged

The OrdinaryDiffEqCore failure reproduces locally byte-for-byte against the CI log before the change, and resolves to OrdinaryDiffEqCore 4.11.1 from lib/OrdinaryDiffEqCore/ after.

This is resolution only. I have no CUDA device, so I have not run the GPU tests themselves. What this PR establishes is that the environments resolve, and that they now resolve to the working tree.

Two related problems this PR does not fix

1. lib/StochasticDiffEq/test/gpu does using StochasticDiffEq and using DiffEqNoiseProcess, but its Project.toml declares neither in [deps] (only CUDA, DiffEqGPU, Statistics, Test). That is a missing-dependency bug rather than a missing-source one, it would fail at load rather than resolve, and its group (WeakAdaptiveGPU) is local_only + gpu-pinned so it does not currently run. I left it alone rather than add deps I cannot exercise.

2. OrdinaryDiffEqBDF [GPU] and OrdinaryDiffEqDefault [GPU] were red for a different reason — they failed earlier, at the sublibrary's own project, on NonlinearSolve: OrdinaryDiffEqNonlinearSolve declared a floor of 4.24.0 while the registry topped out at 4.23.0. NonlinearSolve 4.24.0 has since been released, and both lib/OrdinaryDiffEqBDF and lib/OrdinaryDiffEqDefault now resolve cleanly, so that one has self-resolved. Worth noting as a pattern though: a compat floor landed ahead of the release it depended on.

Separately, six GPU jobs in recent history are cancelled, not failed — no runner carrying the gpu label picked them up. That is a fleet/scheduling matter, unrelated to this PR.

---

Links

• Companion PRs: Stop NoncommutativeConvergence from retaining 270 GiB of Lévy area coefficients #4044, Share the SROCK tableau vectors instead of rebuilding them per cache #4050
• A failing job showing the resolver error: https://github.com/SciML/OrdinaryDiffEq.jl/actions/runs/30019105754

🤖 Generated with Claude Code

https://claude.ai/code/session_013WW2jGeoWZVZu7AiscUNSz