ci: publish cytnx to PyPI on tag (stable) and master push (.devN nightly)

[IvanaGyro]

Summary

Replace the TestPyPI-on-PR/tag flow with two distinct release pipelines that share one PyPI project name, following the numpy / scipy convention:

• stable — release_pypi.yml is restricted to v* tag pushes and manual workflow_dispatch, and publishes the resulting wheels to production PyPI as cytnx X.Y.Z.
• nightly — new release_pypi_nightly.yml triggers on every push to master (PR merges) and on manual workflow_dispatch, and publishes wheels to the same cytnx PyPI project but version-stamped MAJOR.MINOR.PATCH.devYYYYMMDDHHMM (PEP 440, UTC).

pip install cytnx continues to resolve to the latest stable release (PEP 440 excludes pre-releases by default). pip install --pre cytnx resolves to the most recent nightly. One PyPI project, one trusted-publisher entry, two channels distinguished by the version string — same pattern as numpy, scipy, cython, etc.

Commits

1. build: refactor optional-deps; add release-tools group — collapse dev extras down to cytnx[test] + cytnx[coverage] (single source of truth per leaf group) and add a new release-tools extras group containing tomlkit, consumed only by the release pipeline.
2. build: add CYTNX_VERSION_TAG env hook for dev-version suffixes — introduce CYTNX_VERSION_FULL in CMakeLists.txt that initialises to the numeric CYTNX_VERSION and is extended with $ENV{CYTNX_VERSION_TAG} when that variable is set. Used only for the CYTNX_VERSION compile definition (i.e. cytnx.__version__); numeric-only consumers (project(VERSION ...), target SOVERSION, libname) are untouched. Also adds CYTNX_VERSION_TAG to the cibuildwheel Linux environment-pass so the variable crosses into the manylinux container. No-op when the env var is unset.
3. build: add nightly-release pyproject stamping helper — tools/prepare_nightly_release.py uses tomlkit to rewrite pyproject.toml in place (dynamic = ["version"] removed, static version = "X.Y.Z.devYYYYMMDDHHMM", [tool.scikit-build.metadata.version] removed) and appends CYTNX_VERSION_TAG=.devYYYYMMDDHHMM to $GITHUB_ENV. Reuses the regex from [tool.scikit-build.metadata.version].regex to read version.cmake, so the regex lives in exactly one place. Stand-alone; not wired up yet.
4. ci: switch release_pypi.yml from TestPyPI to production PyPI — triggers narrowed to v* tags + workflow_dispatch. Drops the pull_request trigger and the PR-merge / PR-keyed ccache steps that went with it. Job renamed ReleaseTestPyPI → ReleasePyPI. Publish destination is production PyPI (no repository-url override). Drops the login-shell defaults block. Every third-party action is pinned to a full commit SHA with the upstream tag retained as a trailing comment.
5. ci: add nightly cytnx dev-release pipeline — new release_pypi_nightly.yml. Triggers on push to master + workflow_dispatch. Installs tomlkit, runs the prep script, builds wheels via cibuildwheel on the same 4-OS matrix as the stable workflow, and publishes to PyPI as a cytnx dev release via the same trusted-publisher entry. Forwards CYTNX_VERSION_TAG into the cibuildwheel build via the step's env: block. Shares the ccache-wheel-${OS}- cache prefix with release_pypi.yml so the two pipelines warm each other's caches.

Why a separate workflow file?

Different triggers, different version-stamping behavior, and a broken nightly should never block a real release (or vice versa). The shared C++ build logic lives in pyproject.toml ([tool.cibuildwheel.*]) and tools/cibuildwheel_*, so the workflow YAML duplication is small.

Version stamping — why timestamp instead of incremental

A monotonic timestamp (devYYYYMMDDHHMM) requires no external state. An incremental devN would need either querying PyPI for the last .devN or storing a counter, both of which race under parallel merges and break on repo moves. The minute-resolution stamp handles multiple merges per day; PyPI rejects duplicate filenames, but two merges within the same minute is extremely unlikely (and a re-run picks up a new minute).

One-time setup required before merge (manual on PyPI)

These workflows use trusted publishing — no API tokens are stored in the repo. The following must be configured on PyPI before either workflow can publish:

• cytnx project — add a trusted publisher with repository Cytnx-dev/Cytnx, workflow release_pypi.yml, job ReleasePyPI, no environment.
• same cytnx project — add a second trusted publisher entry with repository Cytnx-dev/Cytnx, workflow release_pypi_nightly.yml, job PublishNightlyPyPI, no environment.

Until both are configured, the pypa/gh-action-pypi-publish step will fail; this is intentional and safe.

Test plan

• Both PyPI trusted-publisher entries created on the cytnx project.
• Manual workflow_dispatch of release_pypi_nightly.yml from this branch (before merge) — verify the wheel filenames look like cytnx-1.0.0.devYYYYMMDDHHMM-* and the upload succeeds.
• Manual workflow_dispatch of release_pypi.yml — verify it builds and publishes cytnx X.Y.Z to production PyPI.
• After merge to master: confirm release_pypi_nightly.yml runs and a cytnx X.Y.Z.devN release appears on PyPI.
• Tag a release (vX.Y.Z) and confirm release_pypi.yml runs and cytnx X.Y.Z lands on PyPI.
• pip install cytnx resolves to the tagged stable; pip install --pre cytnx resolves to the latest nightly.

[gemini-code-assist]

Code Review

This pull request introduces a new script, tools/prepare_nightly_release.py, which automates updating pyproject.toml for nightly releases by parsing version information from version.cmake and appending a UTC timestamp. The code review feedback focuses on making the script more robust against formatting changes. Specifically, the reviewer suggests parsing version components individually rather than assuming they are adjacent, using flexible regular expressions instead of exact string replacement for updating package metadata, and refining the regex used to strip the scikit-build metadata block to prevent premature matching.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 29.23%. Comparing base (8c7ee11) to head (d91029c).
⚠️ Report is 19 commits behind head on master.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #866      +/-   ##
==========================================
+ Coverage   29.05%   29.23%   +0.17%     
==========================================
  Files         241      241              
  Lines       35519    35559      +40     
  Branches    14807    14822      +15     
==========================================
+ Hits        10319    10394      +75     
+ Misses      18039    17941      -98     
- Partials     7161     7224      +63     

Flag	Coverage Δ
cpp	28.82% <ø> (+0.15%)	⬆️
python	52.71% <ø> (+1.64%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
C++ backend	30.43% <ø> (+0.15%)	⬆️
Python bindings	17.09% <ø> (+0.20%)	⬆️
Python package	52.71% <ø> (+1.64%)	⬆️
see 13 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8c7ee11...d91029c. Read the comment docs.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[IvanaGyro]

I plan to follow SPEC 4 to release the nightly build. This is adopted by numpy, scipy and some scientific Python packages. I am requesting access of Scientific Python Nightly Wheels to release the nightly build on scientific-python/upload-nightly-action#167. We will not merge this PR until we get access.