Самодостаточная среда выполнения
Как движок Apothem запускается из любого чекаута — вендоренные зависимости, модель вызова PYTHONPATH=src и начальная загрузка дерева плагина.
Самодостаточная среда выполнения
Движок Apothem — это самодостаточная среда выполнения: он работает без реестра,
прямо из любого чекаута или размещённого дерева исходного кода, потому что его
сторонние зависимости поставляются вместе с ним. Это обеспечивают две
части — дерево вендоренных зависимостей и модель вызова python -m, которой не
нужны установленные консольные скрипты.
Дерево вендоренных зависимостей
Стек проверки и сериализации вендорен в виде исходного кода на чистом Python
под src/apothem/_vendor/, каждый пакет — рядом с файлом лицензии из upstream:
yaml(парсер/эмиттер на чистом Python; необязательное C-расширение libyaml не поставляется)jsonschemaс цепочкой его зависимостей:attrs(и его псевдонимattr),referencingиjsonschema_specificationsrpds— шим на чистом Python, который заново реализует поверхностьHashTrieMap,HashTrieSetиList, используемуюjsonschemaиreferencing, на основе встроенных типов, так что стек работает без единого скомпилированного расширенияtyping_extensions
Вендоренные копии имеют приоритет над любой версией, установленной в системе:
начальная загрузка плагина, npm-шим, установщики и сама точка входа
python -m apothem — каждый помещает каталог вендоренных зависимостей в
sys.path перед site-packages. Политика отбора — что вендорится, что нет и как
обновляются вендоренные пакеты — задокументирована в
стратегии вендоринга зависимостей.
Две зависимости остаются вне дерева: click и rich — библиотеки для
работы с терминалом, которые импортирует CLI. Они должны быть импортируемы в
интерпретаторе, запускающем движок; установщики проверяют обе, называют
отсутствующую и предлагают установить её за вас — с вашего подтверждения или
автоматически с --yes / APOTHEM_AUTO_INSTALL_DEPS=1. На всех остальных
каналах точка входа проверяет обе средствами стандартной библиотеки до импорта
CLI, а отсутствие любой из них останавливает её с ошибкой, в которой названа
точная команда pip для запущенного интерпретатора (при --json — JSON-конверт
с кодом runtime.dependency_missing).
Модель вызова python -m
Apothem намеренно не объявляет консольных скриптов в pyproject.toml —
консольные скрипты существуют, только когда менеджер пакетов помещает их в
PATH, а самодостаточная среда выполнения никогда не предполагает его наличия.
Вместо этого у движка две поверхности вызова:
| Поверхность | Вызов | Контекст |
|---|---|---|
| CLI движка | python -m apothem <command> | Дерево исходного кода с src/ в PYTHONPATH (чекаут, кэш npx, дерево плагина) |
| Среда выполнения хуков | <resolved CPython> "<harness-root>/.apothem/support/hooks/dispatch.py" <event> | Материализация Claude Code: копия в общем дереве .apothem/support/ корня окружения, по абсолютному пути |
python -m apothemзапускаетsrc/apothem/__main__.py, который помещаетsrc/apothem/_vendorвsys.path, проверяет, чтоclickиrichимпортируемы, затем вызываетapothem.cli:main— группу команд Click.- Записи хуков в материализованном
settings.json/hooks.jsonвызывают диспетчер (а для Claude Code — шлюз соответствия в<harness-root>/.apothem/support/conformity/gate.py) по абсолютному пути скрипта. Оба — автономные скрипты на стандартной библиотеке, которые сами настраивают свойsys.path, а фикстуры схем для шлюза лежат рядом с ним в<harness-root>/.apothem/support/schemas/, поэтому хуки работают без импортируемого пакетаapothemна хосте. Шаблоны содержат токен${HARNESS_ROOT}, которыйapothem installподставляет как реальный путь к корню окружения в форме с прямыми слешами. - В чекауте исходного кода модульные формы
python -m apothem.hooks.dispatchиpython -m apothem.conformity.gateзапускают тот же код для разработки.
Каталог пакета становится импортируемым, если добавить каталог src/ из
чекаута в начало PYTHONPATH:
PYTHONPATH="$HOME/.apothem/src" python -m apothem <command>Когда лаунчер apothem не находится в PATH, install.sh по завершении выводит эту форму: каталог с вендорными библиотеками стоит перед src/, а вместо python указан найденный им CPython. install.ps1 выводит те же два параметра в форме PowerShell: присваивание $env:PYTHONPATH, которое объединяет каталоги вендорных библиотек и src/ через ;, затем & '<CPython>' -m apothem <command>.
Начальная загрузка дерева плагина
Плагин Claude Code упаковывает движок под <plugin_root>/lib/apothem, а не
полагается на PYTHONPATH. Модуль начальной загрузки
apothem.lib.plugin_bootstrap предоставляет bootstrap_syspath, которая
идемпотентно добавляет <plugin_root>/lib и каталог вендоренных зависимостей в
начало sys.path, чтобы import apothem и каждая вендоренная зависимость
разрешались из дерева плагина. Некорректное дерево (отсутствует lib/)
вызывает PluginBootstrapError, а не молча импортирует устаревшую системную
копию.
Что установщик размещает на диске
Скриптовые установщики размещают git-клон дерева исходного кода в ~/.apothem
(переопределяется через APOTHEM_HOME) и запускают движок из него — никакие
пакеты Python не устанавливаются в site-packages, кроме необязательного
предложения установить предварительные требования click / rich. Клон — это
полный репозиторий, включая набор тестов и сайт документации, которые среда
выполнения никогда не импортирует, и на то есть две осознанные причины: движок
материализует свои группы — правила, навыки, команды и шаблоны — прямо из
дерева в каждое окружение, поэтому дерево является живым источником истины, а не
только средой выполнения; а каталог .git остаётся на месте, чтобы
apothem update извлекал тег релиза в существующем клоне вместо повторного
скачивания.
Такая схема запуска из исходного кода — тот же паттерн, который используют
инструменты вроде nvm, pyenv и oh-my-zsh: несколько мегабайт исходного
кода плюс история, удаляемые за один шаг деинсталлятором (системного состояния,
которое нужно откатывать, нет). Более компактный вариант — мелкий или
разреженный чекаут без tests/ и site/ — возможен, но ценой отказа от
обновления на месте на основе git с проверкой подписи; текущая схема
предпочитает простое проверяемое обновление минимальному занимаемому месту на
диске.
Как среда выполнения находит Python
Одношаговые установщики и npx-шим опрашивают разные имена, но применяют одни и
те же правила. Установщики опрашивают python3, python и имена с версией (от
python3.14 до python3.10). npx-шим опрашивает APOTHEM_PYTHON, если эта
переменная задана, затем python3, python и py -3; имён с версией у него
нет. Оба отклоняют шимы-лаунчеры Microsoft Store и принимают первого кандидата,
сообщающего версию 3.10 или новее. При запуске из дерева исходного кода
установщики повторно используют поставляемый в комплекте локатор
hooks/lib/find-python, который применяет ту же нижнюю границу версии.
Рекомендуемый следующий шаг
Запустите python -m apothem --help с каталогом src/ из чекаута в
PYTHONPATH, чтобы убедиться, что путь самодостаточного CLI разрешается на
вашем хосте.
Рабочий процесс установки
Как apothem install, update и uninstall работают от начала до конца.
Стратегия внутреннего встраивания зависимостей
Какие сторонние пакеты Apothem встраивает внутрь под src/apothem/_vendor/, какие остаются системными предварительными требованиями и как обновляются внутренние копии.