CaltechExperimentalGravity / CaltechExperimentalGravity/system_ident

Stage H: deployment environment — probe a modern CDS-capable env, else clone the site CDS env

Open
#22 4 comments 0 reactions 0 assignees View on GitHub
enhancement
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.