Formalize temporary Sigima development snapshots in DataLab-Web CI

[PierreRaybaut]

Context

DataLab-Web occasionally needs functionality that has already been merged into develop in Sigima but is not yet available in a published Sigima release.

The current example is the annotation API work used by DataLab-Web before Sigima 1.3.0 is released. PR #17 temporarily replaced the normal Sigima requirement with a source archive pinned to commit:

4442ada873655f63fabd14369fd11170f75a28b4

and added a helper (scripts/build_sigima_wheel.py) plus duplicated CI steps to build a Pyodide-installable wheel from that snapshot.

This is a legitimate integration need and is likely to happen again. However, it should be made explicit and safe rather than treated as an ad-hoc dependency override.

Goal

Introduce a lightweight, reproducible mechanism for DataLab-Web to consume a specific Sigima development snapshot when required, while ensuring that released DataLab-Web builds always use an explicitly published Sigima version.

The mechanism should preserve two properties:

1. development can consume Sigima features before the next Sigima release;
2. CI remains reproducible by pinning an immutable commit SHA rather than tracking Sigima/develop directly.

Proposed direction

• Keep a stable Sigima requirement for normal builds/releases.
• Introduce a single explicit development override (for example SIGIMA_DEV_REF, VITE_SIGIMA_DEV_REF, or equivalent) containing a full Sigima commit SHA when cross-repository integration requires an unreleased snapshot.
• Centralize this override in one place instead of embedding a direct GitHub archive requirement in requirements-dev.txt and duplicating the build logic conceptually across workflows.
• Keep building a wheel for Pyodide as long as this is required, but treat that as the standard snapshot mechanism rather than a one-off workaround.
• Add a release guard: release workflows must fail if a Sigima development snapshot override is still active.
• When the corresponding Sigima version is published, remove the development override and pin DataLab-Web to the published version that was actually qualified.

If this pattern becomes frequent, consider moving the source-snapshot wheel build logic to Sigima itself (e.g. a reusable/composite GitHub Action), so consumers only specify the Sigima SHA and Sigima remains responsible for building a correct wheel.

Immediate cleanup for Sigima 1.3.0

Once Sigima 1.3.0 is published:

• replace the current 4442ada... snapshot with the published Sigima 1.3.0 dependency;
• ensure DataLab-Web release builds are qualified against that exact published version;
• remove any CI-specific workaround that is no longer needed;
• keep the generalized development-snapshot mechanism only if it remains useful for future cross-repository integration;
• verify that the release workflow cannot publish while a development snapshot is configured.

Non-goal

This is not about publishing Sigima release candidates or development versions to PyPI. The target use case is earlier in the development cycle: consuming a specific, already-merged commit from Sigima/develop before the next Sigima release is ready.

[PierreRaybaut]

Status and closure criteria

Phase 1 now provides the infrastructure required by this issue:

• sigima-dependency.json is the single source of truth for the exact published requirement and the temporary development SHA.
• CPython, Pyodide, CI, and performance jobs resolve Sigima through that manifest.
• All release entry points intentionally fail while developmentRef is non-null, so a development snapshot cannot leak into a release.

This issue should remain open until the published dependency has been qualified end to end.

Remaining work before closing

Once sigima==1.3.0 is available from PyPI:

1. Set developmentRef to null in sigima-dependency.json, while keeping publishedRequirement pinned to sigima==1.3.0.
2. Run the complete qualification against the PyPI package only, with no local PYTHONPATH, snapshot wheel, or VITE_SIGIMA_INSTALL_SPEC override:
   • Python tests
   • Vitest, ESLint, and Prettier checks
   • Playwright end-to-end tests
   • release build and release guard
3. Confirm that the release bundle contains no development SHA, GitHub archive URL, /@fs/ URL, or local wheel path.
4. Land the final change as chore(deps): qualify Sigima 1.3.0 with Closes #18.

Until all of these checks pass, related commits should use Refs #18 rather than closing the issue.