Files
computer-playbook/scripts/meta/env
kevinveenbirkenbachandClaude Opus 4.7 00c4246c3a refactor(env): introduce INFINITO_VENV_DIR SPOT, fix dev image build
Adds INFINITO_VENV_DIR=/opt/venvs/infinito to default.env (registered
in passthrough's STATIC_KEYS so make dotenv propagates it to .env) and
threads it through the build chain: compose.yml forwards it as a build
arg; scripts/image/push.sh asserts and --build-args it; the Dockerfile
declares the matching ARG/ENV and derives PYTHON/PIP/PATH from the
variable. scripts/meta/env/python.sh now prefers the value when set
before its fallback discovery so the SPOT is effective in env
resolution.

Fixes the dev image build regression where 'infinito --version' in
scripts/docker/entry.sh exited 127. Root cause: the Dockerfile RUN
SHELL uses bash -lc, which sources /etc/profile and resets PATH to
the Debian default, dropping ${INFINITO_VENV_DIR}/bin from it. The
fix invokes the script via its absolute path "${INFINITO_VENV_DIR}/bin/infinito"
so the post-install version check no longer depends on a PATH that
the login-shell init has just clobbered.

scripts/lint/wrapper.sh's existing PATH-reset note now references the
variable instead of the literal path. test-install-make.yml and
test-install-pkgmgr.yml read INFINITO_VENV_DIR from default.env up
front, pass it into their pkgmgr containers, and source the venv
activate script via the variable.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-28 22:12:19 +02:00
..
…

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.