Установка нужной версии Python на VPS

Системный Python в дистрибутиве часто отстаёт на пару версий, а трогать его напрямую опасно — на нём висят apt и системные утилиты. Разбираем два безопасных способа поставить нужную версию: pyenv (сборка любой версии в домашней директории) и deadsnakes (готовые пакеты для Ubuntu).

Почему нельзя трогать системный Python

В Debian и Ubuntu на системном интерпретаторе завязаны apt, apt-listchanges, unattended-upgrades и десятки утилит. Если вы снесёте его или подмените командой make altinstall не туда — сломаете пакетный менеджер и рискуете остаться без доступа к серверу.

Правильный подход: системный Python не трогаем вообще, а нужную версию ставим отдельно и подключаем через виртуальные окружения. Ниже — два рабочих пути. Первый (pyenv) собирает любую версию из исходников в вашей домашней директории и не требует прав root для самого интерпретатора. Второй (deadsnakes) ставит готовый пакет из PPA — быстрее, но только на Ubuntu и только те версии, что уже собраны мейнтейнерами.

Определиться помогает простой критерий. Если проект требует свежайший релиз или, наоборот, старую версию, которой уже нет в репозиториях, а также если вы на Debian — берите pyenv. Если вы на Ubuntu и вам нужна распространённая версия вроде 3.11 или 3.12 без ожидания сборки — deadsnakes сэкономит время. Держать оба механизма на одном сервере тоже допустимо, они не конфликтуют.

Быстрая NVMe у MAATRIX здесь кстати: сборка CPython из исходников на AMD EPYC занимает минуты, а не полчаса, как на медленных дисках бюджетных провайдеров. Если версий приходится собирать много (например, тестируете совместимость под 3.9, 3.11 и 3.12), выигрыш по времени становится ощутимым.

Способ 1. pyenv — любая версия из исходников

pyenv собирает CPython в домашней директории и переключает версии одной командой. Сначала ставим зависимости для сборки (пример для Ubuntu/Debian):

sudo apt update && sudo apt install -y make build-essential libssl-dev zlib1g-dev \
  libbz2-dev libreadline-dev libsqlite3-dev curl git libncursesw5-dev \
  xz-utils tk-dev libxml2-dev libxmlsec1-dev libffi-dev liblzma-dev

Устанавливаем сам pyenv официальным инсталлером:

curl -fsSL https://pyenv.run | bash

Добавляем pyenv в оболочку (для bash — в ~/.bashrc):

echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bashrc
echo '[[ -d $PYENV_ROOT/bin ]] && export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(pyenv init - bash)"' >> ~/.bashrc
exec "$SHELL"

Смотрим доступные версии, ставим нужную и делаем её глобальной:

pyenv install --list | grep -E '^  3\.12'
pyenv install 3.12.7
pyenv global 3.12.7
python --version   # Python 3.12.7

Команда pyenv local 3.12.7 в каталоге проекта закрепит версию только для него — создастся файл .python-version.

Способ 2. deadsnakes — готовые пакеты для Ubuntu

Если не хочется ждать сборку, на Ubuntu есть PPA deadsnakes с предсобранными пакетами. Подключаем репозиторий и ставим версию:

sudo apt install -y software-properties-common
sudo add-apt-repository -y ppa:deadsnakes/ppa
sudo apt update
sudo apt install -y python3.12 python3.12-venv python3.12-dev

Важно: пакет ставится как python3.12 и не перезаписывает системный python3. Вызывайте его явно по имени.

deadsnakes работает только на Ubuntu (для Debian используйте pyenv). Версии выходят с задержкой в несколько дней после релиза.

Виртуальное окружение под проект

Какой бы способ вы ни выбрали, приложение запускайте в отдельном venv, а не глобально:

python3.12 -m venv /opt/myapp/venv
source /opt/myapp/venv/bin/activate
pip install --upgrade pip
pip install -r requirements.txt

Внутри venv команда python указывает ровно на ту версию, из которой окружение создано. Это изолирует зависимости проектов друг от друга и от системы: обновление пакета в одном проекте не заденет другой, а системным утилитам на apt-пакетах вообще ничего не грозит. Для продакшена venv кладут рядом с приложением (как /opt/myapp/venv), чтобы systemd-юнит и деплой-скрипты ссылались на стабильный абсолютный путь к интерпретатору.

Деактивировать окружение можно командой deactivate, но для запуска в фоне это не нужно: достаточно вызывать бинарник напрямую по полному пути, например /opt/myapp/venv/bin/python app.py. Так делают в systemd-юнитах и cron-задачах, где активировать окружение через source негде.

Частые ошибки

• ModuleNotFoundError: No module named '_ctypes' — не был установлен libffi-dev до сборки pyenv. Доставьте пакет и пересоберите версию.
• ssl module is not available — забыли libssl-dev. Симптом: pip не может ходить в PyPI.
• Команда python после pyenv install не поменялась — не выполнили eval "$(pyenv init - bash)" или не перезапустили оболочку.
• Пытаетесь sudo pip install в системный Python — так делать нельзя, ломает apt. Только venv.

Частые вопросы