Skip to content
Apothem
Архитектура

Самодостаточная среда выполнения

Как движок Apothem запускается из любого чекаута — вендоренные зависимости, модель вызова PYTHONPATH=src и начальная загрузка дерева плагина.

Самодостаточная среда выполнения

Движок Apothem — это самодостаточная среда выполнения: он работает без реестра, прямо из любого чекаута или размещённого дерева исходного кода, потому что его сторонние зависимости поставляются вместе с ним. Это обеспечивают две части — дерево вендоренных зависимостей и модель вызова python -m, которой не нужны установленные консольные скрипты.

Дерево вендоренных зависимостей

Стек проверки и сериализации вендорен в виде исходного кода на чистом Python под src/apothem/_vendor/, каждый пакет — рядом с файлом лицензии из upstream:

  • yaml (парсер/эмиттер на чистом Python; необязательное C-расширение libyaml не поставляется)
  • jsonschema с цепочкой его зависимостей: attrs (и его псевдоним attr), referencing и jsonschema_specifications
  • rpds — шим на чистом 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 разрешается на вашем хосте.

On this page