0 Fork 0

mirror of https://github.com/kevinveenbirkenbach/computer-playbook.git synced 2026-11-06 19:01:54 +00:00

Files

T

kevinveenbirkenbachandClaude Opus 4.7 3fe215aaa6 fix(test-runner): source load.sh + prefer project venv over ambient VIRTUAL_ENV

`make test-unit` (docker runner) reached run.sh inside the container via
`bash --login`, which never sources the project's env-loader. PYTHON stayed
unset, so the test invocation fell back to the system python3 — which has
none of the runtime deps (ruamel, ansible, bcrypt, requests, certifi,
humanfriendly), producing 132+ ModuleNotFoundError errors.

run.sh now sources scripts/meta/env/load.sh itself (idempotent via
INFINITO_ENV_LOADED), so the env layer applies regardless of how the shell
was spawned.

While load.sh's detect.sh (now scripts/meta/env/python.sh) correctly walks
/opt/venvs and ~/.venvs to find the venv, an ambient VIRTUAL_ENV from a
different project (e.g. /root/.venvs/pkgmgr in pkgmgr's container) would
hijack the resolution. python.sh now scans the project-named venv candidates
first and only falls back to VIRTUAL_ENV when no project venv exists.

Also moves scripts/meta/python/detect.sh to scripts/meta/env/python.sh so the
env-related helpers live under one directory; updates the load.sh source
pragma and the lint-test path that scans it for INFINITO_* registrations.

`make test-unit` goes from 1262 tests / 132 errors to 1999 tests / 0 errors.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-21 14:55:10 +02:00

load.sh

fix(test-runner): source load.sh + prefer project venv over ambient VIRTUAL_ENV

2026-05-21 14:55:10 +02:00

python.sh

fix(test-runner): source load.sh + prefer project venv over ambient VIRTUAL_ENV

2026-05-21 14:55:10 +02:00

README.md

docs: drop stale requirement refs + reflow soft-wraps to one sentence per line

2026-05-09 05:00:46 +02:00

README.md

Environment Layer 🌍

This directory contains the shared environment bootstrap layer for Infinito.Nexus scripts. ✨

Its purpose is to keep runtime configuration centralized, deterministic, and easy to reuse across local runs, CI, and container-based execution. 🧭

The design follows simple composition principles so environment state can be loaded safely and consistently without duplicating logic in many places. 🧱

Use the directory-level entrypoint for sourcing this environment context in scripts and automation. ✅

Modules 📦

The directory has two kinds of env modules:

Always-on modules are composed by all.sh and SHOULD be sourced by anything that needs the standard project environment (Python interpreter, distro defaults, runtime context, inventory paths, GitHub markers): python.sh, runtime.sh, defaults.sh, inventory.sh, github.sh.
On-demand modules MUST NOT be composed into all.sh because they encode an intent that only makes sense in a specific call path. The deploy-only marker is the canonical example:
- ci.sh exports INFINITO_MAKE_DEPLOY=1 so MODE_CI (defined in group_vars/all/01_modes.yml) flips to true for the duration of a make-driven deploy. It is sourced by every deploy entry-point under scripts/tests/deploy/local/deploy/. Sourcing it from all.sh would set the marker for unrelated make test* or make build* recipes too, which is exactly what the service-gating contract forbids.