Umgebungsvariablen des Installers
Den Skript-Installer (Ziel, Quelle, Harness, Profil, Verifizierung) über Umgebungsvariablen steuern.
Ziel: install.sh / install.ps1 steuern, ohne das Skript zu bearbeiten, indem
Sie Umgebungsvariablen setzen, bevor Sie es ausführen.
Voraussetzungen
- Eine POSIX-Shell (
bash) oder PowerShell 5.1+. Die PowerShell-Beispiele unten rufenpwsh(PowerShell 7+) auf. Führen Sie unter Windows PowerShell 5.1 stattdessenpowershell -NoProfile -ExecutionPolicy Bypass -File install.ps1aus. - Die Variablen werden einmalig am Anfang des Installers gelesen; setzen Sie sie daher im selben Befehl (oder exportieren Sie sie zuerst) und führen Sie dann den Installer aus.
Die Installer-Variablen
| Variable | Steuert | Standardwert |
|---|---|---|
APOTHEM_HOME | Installationsziel für den geklonten Quellbaum | $HOME/.apothem |
APOTHEM_REPO | Zu klonendes Git-Remote | https://github.com/ahmed-g-gad/apothem |
APOTHEM_REF | Auszucheckende Git-Ref; ungesetzt wird das neueste signierte vMAJOR.MINOR.PATCH-Tag aufgelöst, ein Tag-Wert pinnt sie, main wählt den beweglichen Branch. Eine Ref, die kein Tag ist, etwa main, bricht ab, sofern nicht APOTHEM_ALLOW_UNVERIFIED=1 gesetzt ist. | ungesetzt (neuestes signiertes Tag) |
APOTHEM_ALLOW_UNVERIFIED | Stuft einen Fehlschlag der Tag-Signaturprüfung von einem fatalen Abbruch zu einer Warnung herab, wenn auf 1 gesetzt | 0 (verifizieren, fail-closed) |
APOTHEM_VERIFY | signature verifiziert die GPG-Signatur des Release-Tags; checksum installiert das Plattform-Archiv des Releases, nachdem dessen SHA-256 gegen die SHA256SUMS des Releases geprüft wurde (Integrität, kein Nachweis darüber, wer es veröffentlicht hat) | signature |
APOTHEM_RELEASE_BASE | Download-Basis für den Prüfsummenmodus | <APOTHEM_REPO>/releases/download |
APOTHEM_SOURCE | Expliziter lokaler Quellbaum, der statt eines Klons verwendet wird | ungesetzt (klonen) |
APOTHEM_HARNESS | Zu installierender Harness im Benutzer-Geltungsbereich (antigravity, claude-code, codex, hermes, open-claw, opencode, qwen-code). Der Installer übergibt kein --project, daher schlägt ein Harness im Projekt-Geltungsbereich mit project.required fehl; installieren Sie solche Harnesses anschließend mit apothem install --harness NAME --project PATH. | claude-code |
APOTHEM_PROFILE | Pfad zur YAML-Datei des gemeinsamen Profils | $HOME/.config/apothem/profile.yaml |
APOTHEM_SKIP_VERIFY | Überspringt den Verifizierungsschritt nach der Installation, wenn auf 1 gesetzt | 0 (Verifizierung läuft) |
APOTHEM_AUTO_INSTALL_DEPS | Installiert die fehlenden Voraussetzungen click / rich automatisch und ohne Nachfrage, wenn auf 1 gesetzt | 0 (Nachfrage, oder Ablehnung in einer nicht interaktiven Pipe) |
APOTHEM_BIN_DIR | Verzeichnis für den abgelegten apothem-Befehls-Shim | $HOME/.local/bin (POSIX); %LOCALAPPDATA%\Microsoft\WindowsApps (Windows) |
NO_COLOR | Schaltet farbige Ausgabe ab, wenn auf einen beliebigen Wert gesetzt (no-color.org); Farbe ist außerdem immer dann aus, wenn die Ausgabe kein Terminal ist (eine Pipe, eine Datei, ein CI-Log) | ungesetzt (Farbe nur in einem interaktiven Terminal) |
APOTHEM_SOURCE hat Vorrang vor einem Klon: Ist die Variable auf einen Checkout
gesetzt, der src/apothem enthält, verwendet der Installer ihn direkt, rührt
APOTHEM_REPO / APOTHEM_REF niemals an und überspringt die Tag-Auflösung und
die Signaturverifizierung (es wird nichts abgerufen, das zu verifizieren wäre).
Wenn APOTHEM_HOME auf ein vorhandenes Verzeichnis zeigt, das kein Git-Klon
ist, weigert sich der Installer, es zu löschen: Verschieben Sie es beiseite,
richten Sie APOTHEM_HOME auf einen anderen Ort, oder übergeben Sie --yes
(-Yes unter Windows), um das Ersetzen zu autorisieren. Ein veraltetes leeres
Verzeichnis wird ohne das Flag ersetzt.
Vertrauensmodell
Ist kein APOTHEM_REF gesetzt, löst der Installer das neueste signierte
Release-Tag auf und verifiziert dessen Signatur mit git verify-tag, bevor er
irgendeine Konfiguration materialisiert; ein unsigniertes oder manipuliertes Tag
bricht die Installation ab. Ein signiertes Tag, dessen öffentlicher
Maintainer-Schlüssel im lokalen Schlüsselbund fehlt, bricht stattdessen mit einer
Anleitung zum Schlüsselimport ab — importieren Sie den Schlüssel und prüfen Sie
seinen Fingerabdruck gegen den Wert, der in
SECURITY.md
veröffentlicht ist.
Pinnen Sie ein bekanntes
Release mit APOTHEM_REF=<tag> und entnehmen Sie das Tag der
Release-Seite; ein gepinntes
Tag wird auf dieselbe Weise verifiziert. Wählen Sie den beweglichen Branch mit
APOTHEM_REF=main zusammen mit APOTHEM_ALLOW_UNVERIFIED=1; diese Installation
ist unverifiziert, und main allein bricht ab, weil ein Branch kein signiertes
Tag ist. Setzen Sie APOTHEM_ALLOW_UNVERIFIED=1 für sich allein, um nach einem
Verifizierungsfehlschlag mit einer Warnung fortzufahren (Air-Gapped-Betrieb,
lokale Nutzung oder Nutzung vor signierten Releases).
APOTHEM_REF=vMAJOR.MINOR.PATCH bash install.shAPOTHEM_VERIFY=checksum bash install.shAPOTHEM_ALLOW_UNVERIFIED=1 bash install.shSchritte (POSIX bash)
-
Installieren Sie einen anderen Harness im Benutzer-Geltungsbereich als den Standard:
APOTHEM_HARNESS=codex bash install.sh -
Legen Sie das Installationsziel fest und wählen Sie den beweglichen Branch
main. Ein Branch ist kein signiertes Tag, daher braucht der Installer zusätzlichAPOTHEM_ALLOW_UNVERIFIED=1:APOTHEM_REF=main APOTHEM_ALLOW_UNVERIFIED=1 APOTHEM_HOME=/opt/apothem bash install.sh -
Verwenden Sie einen lokalen Checkout und ein eigenes Profil und überspringen Sie die Verifizierung:
APOTHEM_SOURCE=/work/apothem \ APOTHEM_PROFILE=/work/profile.yaml \ APOTHEM_SKIP_VERIFY=1 \ bash install.sh
Schritte (PowerShell)
Setzen Sie jede Variable über $env:, bevor Sie den Installer ausführen:
$env:APOTHEM_HARNESS = 'codex'
pwsh -NoProfile -File install.ps1$env:APOTHEM_ALLOW_UNVERIFIED = '1'
$env:APOTHEM_REF = 'main'
$env:APOTHEM_HOME = 'C:\opt\apothem'
pwsh -NoProfile -File install.ps1$env:APOTHEM_SOURCE = 'C:\work\apothem'
$env:APOTHEM_PROFILE = 'C:\work\profile.yaml'
$env:APOTHEM_SKIP_VERIFY = '1'
pwsh -NoProfile -File install.ps1Verifizieren
Der Installer gibt ✓ Harness <name> installed aus, danach (sofern nicht
APOTHEM_SKIP_VERIFY=1 gesetzt ist) ✓ verify passed. Bestätigen Sie dies
unabhängig:
apothem verify --harness codexFühren Sie für einen Harness im Projekt-Geltungsbereich wie Cursor die
Installation und die Verifizierung nach dem Installer selbst aus, mit
--project:
apothem install --harness cursor --project /path/to/project
apothem verify --harness cursor --project /path/to/projectExistierte das Profil noch nicht, erstellt der Installer eines aus dem Beispiel
und fährt fort, um im selben Lauf zu installieren und zu verifizieren. Die
Identitätsfelder des Beispiels sind Platzhalter, daher gibt die Installation
einen Hinweis aus; bearbeiten Sie $APOTHEM_PROFILE und führen Sie dann
apothem update --harness <name> aus, um Ihre Identität anzuwenden. Ein
--dry-run ohne Profil zeigt eine Vorschau, in der das Beispiel an die Stelle
des Profils tritt, und schreibt nichts.
Verwandte Themen
- Installation behandelt die einmalige Netzwerkinstallation.
- Einen Harness hinzufügen behandelt das Hinzufügen von Harnesses über die CLI nach der Erstinstallation.
Einen Harness hinzufügen
Aktiviere einen Harness-Adapter, damit seine native Konfiguration aus dem gemeinsamen Profil materialisiert wird.
Run the behavioural evals
Measure whether Apothem's commands and subagents fire on the right requests, whether each pipeline stage produces its artifact, and whether a rule changes behaviour, with a cost-capped eval run.