build: vendor-named wheel versions and declared FlagTree/FlagGems/FlagCX (#471)

build: name the wheel’s local version segment after the vendor

The local segment was SDK-shaped and inconsistent: +dtk for DCU, +ppu for
PPU, +metax for MetaX, and nothing at all for CUDA, Ascend, GCU, MUSA,
TsingMicro and BPU – so a CUDA wheel and a MUSA wheel were both plain
2.10.0, and the MetaX hooks overrode the segment per build image
(metax3.8.1.3 on one, metax3.8.0 on the other).
It is now the vendor name everywhere it exists, taken from the wheel_local
column of cmake/flagos_platforms.json, which is also the Nexus pypi lane the
artifact belongs in (flagos-pypi-nvidia, flagos-pypi-hygon, …):
cuda       2.10.0+nvidia       dcu    2.10.0+hygon
gcu        2.10.0+enflame      musa   2.10.0+mthreads
ppu        2.10.0+thead        ascend 2.10.0+ascend
metax      2.10.0+metax        tsingmicro 2.10.0+tsingmicro
bpu        2.10.0              (unchanged: no lane exists for it)
Two hook edits follow from that: set_env_metax.sh no longer exports
FLAGOS_WHEEL_LOCAL per image, and set_env_ppu.sh no longer defaults it to
ppu. Both names are also dropped from the hooks’ export_ci_env lists, which
matter because export_ci_env reads each name with ${!name} under set -u and
would fail on an unset one. Leaving the overrides in place would make the
artifact name a property of the build script rather than of the platform table.
The table is the single source, and it is where a new platform is added.
What the segment no longer carries is the SDK version, which the two MetaX
images did distinguish and which the original comment justified the segment by.
That belongs in FLAGOS_SDK_VERSION, which setup.py already records in
torch_fl/compatibility.json and which –release requires; nothing sets it
today, so both MetaX images now produce the same 2.10.0+metax and their SDK
is recorded as unknown. Wiring it into the hooks is a separate change –
docs/reference/environment-variables.md and the capability-matrix comment in
the platform table both say so.
Tested:

FLAGOS_ACCELERATOR=<platform> python setup.py --version for all nine:
2.10.0+nvidia / +hygon / +enflame / +mthreads / +thead / +ascend / +metax /
+tsingmicro / 2.10.0
bash -n on both edited hooks; python -c "json.load(...)" on the table
pytest tests/unit/test_setup_build.py tests/unit/test_env_registry.py ->
57 passed (two guards fired on this change and are updated with it:
test_setup_build asserted the musa manifest’s wheel_version, which is now
2.10.0+mthreads, and test_env_registry compares the documented default
against torch_fl/_env.py’s registry, which is updated to match)
ruff check / ruff format --check -> clean
full pytest tests/unit -> 951 passed, the same 27 environment-dependent
failures as before this branch

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com

build: declare FlagTree, FlagGems and FlagCX at the versions this wheel pins

pip install torch_fl installed almost none of what the wheel needs. Measured
per platform before this change: flagtree and flagcx appeared nowhere in
setup.py on any platform – they were installed only by the CI hooks – and
flag_gems was declared on five of nine platforms, excluded from DCU, Ascend
and PPU by _vendor_supplies_triton(), whose stated reason was only about
Triton. So a user’s environment got a flagos device with no operator source and
a distributed path staged through the host; the DCU CI log shows that warning
even in CI.
Declaring the three comes with two facts that rule out a range:

flagtree and flagcx are not on PyPI (both 404 on the pypi-proxy repo),
and flag_gems there stops at 5.0.2 while the per-op routing tables in
torch_fl/configs/backends_*.conf are generated against the 5.4.0 cohort –
so flag_gems>=5.0.2 was satisfied by a build this wheel was never
measured on;
a FlagTree build is per-platform: the package name carries the vendor’s own
Triton backend, so flagtree==0.7.0rc2+hcu3.6 for DCU and
==0.7.0rc3+metax3.6 for MetaX. FlagTree installs the triton
distribution, which is why the separate triton>=3.5.1 requirement is now
declared only where no FlagTree build is pinned (tsingmicro, bpu) –
declaring both is what produces Ascend’s “0 active drivers” failure.

The versions come from .github/version-pins.env, the file the CI scripts
source, read as data. A build without it raises rather than falling back to a
floor, because there is no floor that could stand in for the pins.
The resulting declaration matches the pins exactly: flagtree on the seven
platforms whose hook calls install_flagtree, flagcx on the five whose hook
installs it (CUDA, DCU, GCU, MetaX, MUSA), flag_gems everywhere. A new test in
tests/unit/test_ci_version_pins.py holds the two halves together – it reads
setup.py’s own function and asserts each platform declares its pins and that
flagtree/triton never appear together. Verified by breaking it both ways
(dropping the flagcx line and adding a spurious triton line each fail it).
Two incidental findings from building this, both fixed here because they are
the same declaration:

pyproject.toml’s [project.optional-dependencies] already declared a
flagcx extra, unpinned, for an artifact that is not on PyPI. It is
removed: the package is now a pinned requirement wherever a build exists,
and the platforms without one have no FlagCX at all.
setup.py’s extras_require={"cuda": ...} was dead config. setuptools
reports “extras_require overwritten in pyproject.toml
(optional-dependencies)” on every build, so no cuda extra was ever in an
artifact; the CUDA runtime deps are hard requirements on that platform
through _install_requires() regardless, and _cuda_runtime_requires()
becomes unused with it.

Resolution was measured rather than assumed, because the index layout decides
it. For DCU as a cp310 target, the full stack resolves – and each piece comes
from a different place:
flag_gems 5.4.0                   flagos-pypi-hygon
flagcx 0.14.0rc2.post2+dtk2604    flagos-pypi-hygon
flagtree 0.7.0rc2+hcu3.6          flagos-pypi-hosted
PyYAML 6.0.1, packaging 26.3,     pypi-proxy
SQLAlchemy 2.0.52, numpy 2.2.6
Two things that measurement showed and the docs now state: the vendor lane
alone is not enough even where it holds all three FlagOS packages, because
flag_gems itself requires packaging>=26.0 and PyYAML==6.0.1; and flagtree
is not in most lanes, so flagos-pypi-hosted is required. That split is already
how CI is configured (FLAGTREE_INDEX_URL versus FLAGGEMS_INDEX_URL in the
hooks). docs/getting-started/installation.md gains the table and a worked
command.
One thing deliberately not changed: the resolver picks numpy 2.2.6, while
several CI hooks and .github/constraints.txt pin numpy<2 with the reason
“2.x breaks the stock +cpu torch C extensions at import”. That did not
reproduce here – torch 2.10.0+cpu imports with numpy 2.2.6 installed – so no
cap is declared on a constraint that cannot be demonstrated. The discrepancy
between the hooks and the pinned torch is worth its own look.
Tested:

every declared requirement parses with packaging and matches its own
specifier, for all nine platforms
python setup.py egg_info now emits flagtree==0.7.0rc2+hcu3.6,
flag_gems==5.4.0, flagcx==0.14.0rc2.post2+dtk2604 and Version: 2.10.0+nvidia, with no setuptools “overwritten” warning, and no flagcx
or cuda extra
pytest tests/unit/test_ci_version_pins.py tests/unit/test_setup_build.py tests/unit/test_wheel_preflight.py -> 70 passed
ruff check / ruff format --check -> clean
full pytest tests/unit -> 951 passed, the same 27 environment-dependent
failures as before this branch

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com

ci: give the DCU manifest 90 minutes, because it is the one that runs tests/unit

The DCU pipeline was cancelled by its own limit on the last two runs: 58m18s
for a green one (2026-09-28T16:26Z) and 62m26s for the next, which gh pr checks
reports as a failure. Neither run had a failing test – the second had already
printed all 72 of its per-file unit results PASS when the job was cut, and every
step in the job is completed/success. The wall clock was the only thing red.
The reason DCU sits at the edge is that its manifest is the only one that also
runs the whole tests/unit directory, one process per file, on top of a wheel
build and thirteen integration groups. Trimming that group is the wrong fix: it
is what caught the cp310 tomllib collection error this branch series is
fixing (#470), and no other platform runs it. Ascend, the other long manifest,
is already at 120.
Tested:

python -c "yaml.safe_load(open('.github/configs/dcu.yml'))" -> OK
no test or script asserts this value (grep -rn timeout_minutes tests/) –
it is read by all-tests-common.yml and passed to the job
ruff check / ruff format --check -> clean

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com

Co-authored-by: Claude Opus 5 (1M context) noreply@anthropic.com