feat: pixi-managed software environment

[ggmarshall]

Closes #135 (first stage).

Adds a pixi-managed software environment to the production cycle, modeled on legend-simflow's setup, as the path towards removing the execenv container machinery.

Changes

• [tool.pixi] workspace in pyproject.toml: conda-forge + bioconda channels (linux-64); [tool.pixi.dependencies] mirroring the pinned pypi dependencies with the exact production pins (pygama==2.4.1, dspeed==2.1.4, snakemake==9.9.0, …); [tool.pixi.pypi-dependencies] with the repo itself editable plus the four packages not on conda-forge (legend-daq2lh5, legend-dataflow-scripts, both snakemake logger plugins); default/test environments on one solve-group; snakemake / dry / prod [--profile <name>] / test tasks.
• [tool.pixi.activation.env] reproduces the execenv "bare" env vars (LGDO_BOUNDSCHECK, DSPEED_BOUNDSCHECK, PYGAMA_PARALLEL, PYGAMA_FASTMATH, TQDM_DISABLE) — a pixi-managed cycle needs no execenv: section and no containers. With the companion feat(execenv): pixi mode and deprecation of the execenv layer legend-dataflow-scripts#45 change, execenv_pyexe then returns bare console-script names that resolve from the pixi environment, so all 88 rule call sites work unchanged in both modes.
• .pixi/ and pixi.lock gitignored (simflow convention: lock not committed).
• New unit-tests-pixi CI job (prefix-dev/setup-pixi).
• Docs: pixi documented as the recommended installation; dataflow install demoted to the legacy container-site path with a deprecation note; comment in dataflow-config.yaml that execenv: is optional under pixi.

Verified locally (pixi 0.75.0)

• pixi install: full conda solve succeeds with the exact production pins on first try.
• pixi run -e test test: unit suite passes inside the pixi env.
• Inside the env: snakemake --version → 9.9.0, build-tier-dsp et al. on PATH, activation env vars set, and pixi-mode execenv_pyexe(cfg, "build-tier-dsp") returns the bare runnable command.

Follow-ups (out of scope here)

• Rewrite the 88 execenv_pyexe/execenv_prefix call sites to invoke console scripts directly and delete the execenv machinery once container sites have migrated.
• Decide a pixi.lock policy for frozen production cycles (committing the lock at cycle-tag time would make cycles bit-reproducible).

Disclosure per AI_POLICY.md: developed with AI assistance (Claude) and reviewed by the submitter.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 62.23%. Comparing base (6ab38e7) to head (bf3e5ca).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #163   +/-   ##
=======================================
  Coverage   62.23%   62.23%           
=======================================
  Files           7        7           
  Lines         662      662           
=======================================
  Hits          412      412           
  Misses        250      250           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Pull request overview

This PR introduces a pixi-managed software environment for legend-dataflow (alongside the existing uv/container-based flow), adds documentation to recommend pixi, and wires up CI to run unit tests inside a pixi environment.

Changes:

• Adds a [tool.pixi] workspace to pyproject.toml, including environments and tasks (prod/dry/snakemake/test) plus activation env vars.
• Documents pixi as the recommended installation path and marks the legacy dataflow install / container machinery as deprecated.
• Ignores .pixi/ and pixi.lock, and adds a new GitHub Actions job to run unit tests via pixi.

Reviewed changes

Copilot reviewed 4 out of 5 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
pyproject.toml	Defines pixi workspace, deps, activation env vars, environments, and tasks.
docs/source/user_manual.rst	Adds pixi-based installation guidance and deprecates the legacy container-site install path.
dataflow-config.yaml	Notes that execenv: can be omitted when running in a pixi-managed environment.
.gitignore	Ignores pixi environment directory and lock file.
.github/workflows/main.yml	Adds CI job to run unit tests within the pixi environment.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ggmarshall]

The 'test' feature actually does carry the test dependencies: pixi's pyproject integration maps [project.optional-dependencies] extras to features of the same name, so the test extra (pytest, pytest-cov, pylegendtestdata) is included in the solve — verified with pixi list -e test (pytest 9.1.1 present, absent from the default env), and pixi run -e test test passes on a clean solve. Added a clarifying comment above the environment table in e3a5e4a so this isn't confusing to readers.

[ggmarshall]

Went one better in e3a5e4a: added osx-64/osx-arm64 to the pixi platforms — the full pinned stack solves cleanly for all three platforms (the LEGEND packages are noarch), so macOS users can pixi install directly rather than reading a caveat.

[iguinn]

Hey George, I would strongly consider setting up pixi in a way that uses "detached environments" and does not store the SW in the same directory as the ref-prod. This has major benefits in transferring data, since the environments have a huge number of small files (right now, if you try to globus a dataset, the .venv is a major slowdown!). I would just keep the lock file in the actual ref-prods.

In addition, we are working on providing versioned and reproducible lock files with legend-analysis-toolkit. I would also strongly consider drawing on one of those and documenting the version of that used. Right now, this isn't quite ready to use, but in the future I think this will be ideal