chore(ci): wrapper repos can't install private fastfields-dlpack in CI

[balbasty]

The wrapper repos (fastfields-numpy/-torch/-cupy/fastfields) install the compiled binding in test.yaml via:

pip install "fastfields-dlpack @ git+https://github.com/fastfields/fastfields-bind-py@main"

This fails on two counts:

1. Private repo, no creds: fatal: could not read Username for 'https://github.com' — the runner has no credentials for the private bind-py.
2. No submodules: even with creds, pip's git clone does not fetch submodules, so the dlpack source build (which needs _fastfields_lib → lib → cpu/cuda → impl → kernels) can't build.

So the wrapper repos' pytest matrix is red for a reason independent of everything else (their ruff lint is green and pinned). Deferred per maintainer decision — it doesn't block the C++/bind-py stack.

Options, best last:

• (a) credentialed install (CI_SUBMODULE_TOKEN via git insteadOf) plus a submodule-aware build — more CI YAML, still a source build per job.
• (b) checkout bind-py with submodules: recursive and pip install ./path from a local checkout.
• (c, recommended) install fastfields-dlpack from the wheel index (fastfields.github.io/whl) once a dlpack wheel is published there — no per-job source build, matches the intended distribution model.

Recommend (c) once the release workflow publishes a dlpack wheel; until then the wrapper pytest legs stay red-by-design.

[balbasty]

Update after re-running a wrapper CI (fastfields-numpy) now that all repos are public:

Public repos fixed cause (1) — pip's top-level clone of fastfields-bind-py@main now succeeds over HTTPS (resolved to 92a8e2d). But the install still fails, at the recursive submodule step:

Running command git submodule update --init --recursive -q
git@github.com: Permission denied (publickey).
fatal: clone of 'git@github.com:fastfields/fastfields-lib.git' into submodule path '_fastfields_lib' failed

Root cause: the .gitmodules files pin submodules with SSH URLs (git@github.com:…). The C++ CI works around this with the actions/checkout token: + an insteadOf HTTPS rewrite, but pip's plain git submodule update has no such rewrite and there's no SSH key on the runner. Public repos clone over HTTPS without auth, not over SSH.

Fix chosen: convert every .gitmodules URL in the chain to https://github.com/…, bottom-up (cpu-impl / cuda-impl → cpu-lib / cuda-lib → lib → bind-py) with a pin bump so each pinned commit carries the HTTPS URL. This also lets the C++ CI drop its token:/insteadOf workaround. (The wheel-index path — option c — remains the longer-term distribution model, tracked separately.)

Queued behind two in-flight PRs that touch the same repos, to avoid racing their pin bumps. Keeping this open until the wrapper source-install goes green.

---

Generated by Claude Code

[balbasty]

Resolved. The .gitmodules SSH→HTTPS conversion + pin cascade is merged across the whole chain (fastfields-kernels ← cpu-impl/cuda-impl ← cpu-lib/cuda-lib ← lib ← bind-py), so pip's recursive git submodule update --init now clones every layer over public HTTPS with no SSH key.

Verified by re-running the fastfields-numpy CI after the cascade (run 30047647677, attempt 3):

• ubuntu-latest 3.9 / 3.11 / 3.12: green — pip install "fastfields-dlpack @ git+…bind-py@main" recursive clone + from-source build + pytest all pass.
• macos-latest 3.9 / 3.11 / 3.12: green — same.
• windows-latest: still fails at the source install — the separate __declspec(dllexport)/import-lib issue, tracked in Windows CI: public symbols need __declspec(dllexport) + import-lib linking fastfields-dlpack#8 (not this issue).

The wrapper repos' from-source install is unblocked on Linux + macOS. Closing.

---

Generated by Claude Code