python-build-standalone
- title
- python-build-standalone
- type
- toolbox
- summary
- Самодостаточные перемещаемые сборки CPython, работающие на любой машине целевой архитектуры
- tags
- python, build-tooling, packaging, astral
- language
- Python
- license
- MPL-2.0
- created
- 2026-07-29
- updated
- 2026-07-29
- lang
- ru
- translation_of
- python-build-standalone
- source_updated
- 2026-07-29
- translated
- 2026-09-01
- translator
- lllm/antigravity/gemini-3.7-flash-medium
python-build-standalone собирает дистрибутивы CPython, которые содержат все свои зависимости и запускаются везде, где поддерживается целевая архитектура. Распакуйте архив в любое место, запустите интерпретатор - и получите полнофункциональный Python с большинством модулей расширения стандартной библиотеки: их зависимости от C-библиотек либо поставляются рядом, либо слинкованы статически. Именно этот механизм стоит за операцией "скачать Python", не требующей ни системного пакетного менеджера, ни компилятора, ни скрипта configure.
Что здесь означает "переносимый"
Сборки ограничены сразу в двух направлениях. Они ограничивают набор процессорных инструкций, которые может генерировать компилятор, благодаря чему дистрибутив, собранный на более новой машине, не падает с ошибкой на старой с той же архитектурой. И они ограничивают набор разделяемых библиотек, требуемых во время выполнения, избавляя от зависимости от конкретных версий OpenSSL, libffi или ncurses на хосте. Заявленная цель - работоспособность дистрибутива на любой системе целевой архитектуры, что значительно сильнее простого утверждения "работает на том дистрибутиве, где собиралось".
Некоторые дистрибутивы содержат не только установленное дерево: они поставляют объектные файлы и библиотеки сборки, а также метаданные о том, как дистрибутив компоновался. Сторонний переупаковщик может пересобрать эти артефакты в собственный Python - например, убрав SQLite или OpenSSL, - что как раз нужно для встраивания интерпретатора внутрь более крупного бинарника вместо отдельной установки. PyOxidizer от Gregory Szorc - родственный проект, занимающийся именно этим, а PyOxy берёт те же дистрибутивы и оборачивает их на Rust в один исполняемый файл интерпретатора.
Публикуются архивы двух вариантов. Полный архив содержит артефакты сборки и описанные выше метаданные. Архив install-only представляет собой готовую к использованию установку - именно то, что нужно, если требуется просто запускать Python.
Особенности, о которых стоит знать перед внедрением
В документации есть целая глава о поведении, отличающемся от системного Python, и это именно тот раздел, который нужно прочесть перед внедрением: неработающие спецклавиши в REPL, отсутствие tix на UNIX, отсутствие pip.exe на Windows, дополнительные шаги при линковке статической библиотеки на macOS, libedit вместо readline на Linux, а также пути времени сборки, оставшиеся в установленном дереве. Последнее обычно вызывает больше всего удивления, поскольку перемещённый дистрибутив всё ещё может содержать строки, указывающие на пути, где происходила сборка. Также есть страница статуса проекта с примечаниями по каждой платформе и тестами CPython, которые падают или пропускаются на конкретной цели, - честный ответ на вопрос "действительно ли это работает везде".
Кто поддерживает проект
Репозиторий находится в организации astral-sh - там же, где uv и Ruff, - тогда как документация по-прежнему отдаётся с gregoryszorc.com и всё ещё описывает PyOxidizer и PyOxy как родственные проекты, без единого упоминания Astral. Так что документация отражает состояние до передачи проекта, а организация в репозитории - текущее положение дел. На практике именно из-за uv у большинства пользователей этот дистрибутив уже лежит на диске, хотя они его специально не выбирали: uv python install скачивает архивы python-build-standalone, а не собирает CPython из исходников. Это включает проект в цепочку поставок, описанную в open-source-security-astral, где механизмы контроля релизов Astral (Trusted Publishing, аттестации Sigstore, неизменяемые релизы) стоят между скомпрометированным CI и каждым интерпретатором, который раздаёт uv. В loopwerk-uv-ux-mess рассматривается другая сторона этой связи: эргономика управления пакетами в uv отстаёт от удобства распространения и установки.
Проблема перемещаемого интерпретатора - это специфичный для Python вариант вопроса, который if-ai-writes-your-code-why-use-python поднимает с другого конца: компилируемый язык даёт единый бинарник даром, а в Python для приближения к этому результату требуется отдельный проект вроде этого.
github.com/astral-sh/python-build-standalone - 4.3k stars, MPL-2.0. Документация на gregoryszorc.com/docs/python-build-standalone.