CaltechExperimentalGravity / CaltechExperimentalGravity/system_ident
Stage H: deployment environment — probe a modern CDS-capable env, else clone the site CDS env
- Dominant language
- Python
- Stars
- 0
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Description
**Stage H (spec §8).** Investigate empirically before committing; the expected answer is
already documented but should be verified on the box rather than inferred.
### The probe
On the deployment machine, dry-run solve a modern environment **together with** the CDS packages
(`foton`, `python-foton`, `python-awg`, `cdsutils`, `nds2-client`) at python 3.12, then 3.11, then 3.10.
Record the outcome in [`notes/cds-hardware-bringup-2026-08.md`](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/notes/cds-hardware-bringup-2026-08.md).
**Expected: unsolvable.** The CDS 3.1.2 control packages are **py3.9-only builds** in that channel, which
is exactly why the sibling project had to change `python>=3.9` → `python=3.9` and drop the `anaconda`
metapackage. If it *does* solve, verify both that the CDS modules import **and** that the py3.9-baseline
test subset passes in it before trusting it.
### Fallback (the expected path)
Clone the site CDS conda environment — it is the ABI reference for the compiled `foton`/`awg`/`nds2`
extensions — then `pip install -e . --no-deps`. All six of this repo's core dependencies (numpy, scipy,
control, slycot, pyyaml, matplotlib) are **already in that lock**, so `--no-deps` is sufficient *and*
mandatory: nothing may bump numpy/scipy underneath those extensions.
Keep the modern `sysid` environment as the primary dev/docs environment either way — this decides only
what runs on the deployment machine.
### Also needed
Unattended `git pull` on the deployment machine needs its **own read-only deploy key for this repo and
forge**. The sibling project's key is registered on a different forge and a different project, so it does
not transfer. Concrete host / account / path values stay in an untracked local access note — **this repo is
public**, unlike the sibling GitLab project that tracks them.
---
**Campaign:** CDS hardware backend · branch [`feat/cds-hardware-backend`](https://github.com/CaltechExperimentalGravity/system_ident/tree/feat/cds-hardware-backend)
· [spec](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/docs/superpowers/specs/2026-08-03-cds-hardware-backend-design.md) · [plan](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/docs/superpowers/plans/2026-08-03-cds-hardware-backend.md) · [handoff](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/notes/cds-hardware-bringup-2026-08.md)
*Code is deferred until the plan and issues have been reviewed.*
Contributor guide
No contributing guide indexed for this repository
Research direction
Read the deployment requirements in the issue and the linked notes/cds-hardware-bringup-2026-08.md, then probe the deployment machine at Python 3.12, 3.11, and 3.10 with the listed CDS packages. Record the solve results; if needed, clone the site CDS environment, install the repository with --no-deps, and verify the CDS imports and py3.9-baseline tests. Document the separate read-only deploy-key setup in an untracked local note.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- anaconda, git, github, python
- Domain
- devops, infrastructure
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100