+ notes: '8 Linux wheels upstream (abi: cp311,cp312,cp313,cp314); no riscv64 on PyPI or pypi.riseproject.dev. Feasible: the compiled surface is one pybind11 extension (index_shuffle, statically linking abseil-cpp) plus a generated protobuf module, and array-record 0.8.3 - the dependency that would have blocked this - is already published here for cp312/cp313/cp314 (no cp311, which sets the matrix). Bazel bootstrapped from source at 7.5.0 like array-record/ray/labmaze, sharing their actions/cache key. Upstream''s `bazel build ...` is unusable on riscv64: 85 BUILD deps reach the @pypi hub, whose test_requirements lock pins jaxlib==0.8.0 and scipy with hashes, and jaxlib has no riscv64 wheel and no sdist - so only the three targets whose output reaches the wheel are built (verified locally in manylinux_2_34_x86_64: the module graph resolves and all three analyse with zero @pypi/jaxlib/scipy fetches). rules_python 1.6.0 carries riscv64 CPython for 3.11-3.14 inclusive. Tests (gotcha 439): upstream''s default CI mode is `bazel test`, one process per py_test target, and its OSS pytest fallback is not a tested path - `pytest --pyargs grain` in one process makes data_loader_test''s 120 tests fail that pass 120/120 alone, and hangs around 4%. So each of the 45 test files runs as its own process, invoked as a module (`python -m grain...`) because ipc/queue.py shadows the stdlib queue when its own directory is sys.path[0], which killed queue_test and variable_size_queue_test; with the env/args upstream''s rules supply (--test_srcdir on data_loader/data_sources/tfrecord_dataset, EXPECTED_FRAMEWORK=NO_FRAMEWORK, PYTHON_VERSION). 9 files dropped: 8 need jax or tensorflow (batch_test among them - it reads sys.modules["jax"] without importing it and its py_test declares @pypi//jax), and multiprocessing_test, which upstream declares no target for and whose __main__ calls an undefined name. dataset_test goes through pytest so grain''s own RUN_IN_PYTEST expectedFailure applies to its two execution-summary tests, which wait on a summary-logging thread that only reports under upstream''s runner. All of that verified in manylinux_2_34_x86_64 against upstream''s released cp312 wheel: data_loader 120, dataset_test 156, traceback_util 18, queue 6, variable_size_queue 19, and no failures in the shipped configuration. Wheel also gains LICENSE.abseil-cpp/LICENSE.pybind11 (both statically linked, upstream ships neither); confirmed setuptools 82 globs them into dist-info/licenses. Local ceiling: no riscv64 bazel compile (the session proxy 403s github.com/pybind/pybind11/archive/*). PR #2124 open; every check still queued on the org''s Actions backlog, so CI has not been proven green yet. Run 35492217884 then came back fully green while building a single wheel: the three interpreter legs were include-only entries ({tag, python}) on a version-only matrix, so GitHub merged them into one combination and only `Build grain 0.2.18 cp314-manylinux_riscv64` ran - gotcha 402, inherited from build-array-record.yml, which grain was derived from. Fixed by making `tag: [cp312, cp313, cp314]` a real dimension crossed with version, the include entries now only mapping tag -> python; expansion re-checked against GitHub''s documented include semantics (3 jobs per version, 6 for two pending versions) and run 35503063718 is the first to queue three build jobs. The same collapse is latent in 58 other jobs repo-wide (noted on gotcha 402; protobuf-py-ext, primp, arro3-core and rigour 2.5.0 have already published incomplete wheel sets).'
0 commit comments