Установка Python 3.13 на Ubuntu 24.04

Ubuntu 24.04 уже идёт с современным Python, но жизнь администратора так устроена, что «стандартной» версии всегда мало. Разработчик просит 3.13, тесты гоняются только на 3.13, да и самому хочется попробовать свежие возможности.

Сделаем это аккуратно: поставим Python 3.13 рядом с системным, не поломаем apt, настроим pip и виртуальные окружения так, чтобы даже новичок разобрался.

Задача: установить Python 3.13 на Ubuntu 24.04, не трогая системный Python, грамотно настроить окружения и избежать типичных граблей.

Системный Python: почему его лучше не трогать

В Ubuntu 24.04 системный Python используется:

пакетным менеджером apt;
скриптами и утилитами из /usr/bin;
сервисами типа cloud-init и прочей «магией» при загрузке.

Если попытаться «обновить Python в системе» и заменить /usr/bin/python3 на 3.13, можно получить отличное утро с неработающим apt и падающими скриптами.

Поэтому сразу фиксируем правила:

Не заменяем /usr/bin/python3 симлинками на 3.13.
Используем Python 3.13 отдельно, вызывая его по имени python3.13.
Всё, что относится к проектам, ставим в виртуальные окружения.

Так мы остаёмся в хороших отношениях и с системой, и с разработчиками, и с безопасностью.

Подготовка Ubuntu 24.04

Сначала — классика: наводим порядок в пакетах.

sudo apt update && sudo apt upgrade -y

Это не только подтягивает обновления безопасности, но и уменьшает шанс, что установка нового Python упрётся в старые зависимости.

Дальше поставим полезные утилиты для работы с репозиториями:

sudo apt install -y software-properties-common

Если ты только что развернул сервер, эти команды могут занять время, но лучше сделать это один раз, чем потом отлавливать странные конфликты версий.

Добавляем репозиторий с Python 3.13

На момент написания этого гайда Python 3.13 в стандартном репозитории Ubuntu 24.04 может отсутствовать или появиться с задержкой. В боевой жизни админа чаще используют проверенный PPA — например, deadsnakes.

Добавляем его:

sudo add-apt-repository ppa:deadsnakes/ppa
sudo apt update

⚠️ Важно для продакшна: PPA — это внешний источник пакетов. В компаниях с жёсткой политикой безопасности обычно нужно согласовать его использование с ответственными за инфраструктуру.

Устанавливаем Python 3.13

Теперь ставим нужную версию Python:

sudo apt install -y python3.13 python3.13-venv python3.13-dev

python3.13 — сам интерпретатор;
python3.13-venv — модуль для создания виртуальных окружений;
python3.13-dev — заголовочные файлы и dev-библиотеки (нужны для сборки некоторых пакетов, например с C-расширениями).

Проверяем, что всё живо:

python3.13 --version

Ожидаем увидеть что-то вроде:

Python 3.13.x

Где x — минорная версия.

Обрати внимание: python3 по-прежнему может указывать на системный Python (например, 3.12). Это нормально. С Python 3.13 мы работаем через явный вызов python3.13.

Устанавливаем pip для Python 3.13

Дальше нам нужен pip, причём именно для этой версии Python. Самый предсказуемый способ на серверах — использовать официальный скрипт установки get-pip.py.

Переходим в домашнюю директорию (просто чтобы файл не валялся в корне проекта или системы):

cd ~
wget https://bootstrap.pypa.io/get-pip.py

Запускаем установку через Python 3.13:

sudo python3.13 get-pip.py

Проверяем:

python3.13 -m pip --version

Если версия отображается и ошибок нет — всё хорошо.

✅ Лайфхак: Используй форму python3.13 -m pip, а не просто pip. Так ты всегда знаешь, к какой версии Python относится команда, и не поймаешь конфликт между системным и пользовательским pip.

Создаём виртуальное окружение под проект

Теперь настроим рабочую среду, в которой не будет конфликтов библиотек.

Создадим каталог проекта, например:

mkdir -p ~/projects/my_service
cd ~/projects/my_service

Создаём виртуальное окружение на базе Python 3.13:

python3.13 -m venv venv

Появится папка venv — это отдельный мини‑мир:

свой интерпретатор Python 3.13;
свой набор библиотек;
ничего лишнего из системы.

Активируем окружение:

source venv/bin/activate

Терминал сменит приглашение, появится префикс вида (venv) — теперь все команды python и pip работают внутри этого окружения.

Проверим, какую версию Python видит окружение:

python --version

Должен быть Python 3.13.

Чтобы выйти из окружения, в любой момент:

deactivate

⚠️ Типичная ошибка новичков — забывают активировать venv и ставят библиотеки глобально. Потом удивляются, почему «после обновления библиотеки упал другой проект». Привычка смотреть на префикс (venv) экономит кучу времени.

Устанавливаем базовый набор библиотек

Представим, что мы готовим окружение для небольшого сервиса и скриптов автоматизации. Внутри активированного venv можно поставить полезные пакеты:

pip install requests

Для реального проекта лучше сразу завести requirements.txt. Пример минимального набора:

requests==2.31.0
fastapi==0.115.0
uvicorn[standard]==0.30.0

Устанавливаем всё разом:

pip install -r requirements.txt

Теперь у нас есть готовый стек для API‑сервиса на Python 3.13.

Совет: версии пакетов лучше фиксировать (как в примере). Это избавит от сюрпризов, когда через полгода ты разворачиваешь такой же проект, а свежая версия библиотеки ведёт себя иначе.

Подводные камни и как их обойти

Разберём самые частые «грабли», на которые наступают админы и разработчики.

Замена системного Python

Кто-то решает «обновить Python» и делает что-то вроде:

sudo ln -sf /usr/bin/python3.13 /usr/bin/python3

Через пару минут выясняется, что apt больше не работает, а некоторые системные утилиты падают с ошибками. Это худший сценарий.

💡 Решение: никогда так не делать. Пусть системный Python остаётся тем, что поставила Ubuntu. Свою версию используем отдельно.

Глобальная установка пакетов через sudo pip

Другой трюк, который ломает систему тихо и незаметно:

sudo pip install <пакет>

Так можно случайно обновить (или заменить) системные библиотеки, от которых зависят другие приложения.

💡 Решение:

ставим пакеты либо в venv,
либо явно через python3.13 -m pip без sudo,
либо используем отдельного пользователя под приложение.

Смешивание Python 3.12 и 3.13

На Ubuntu 24.04 по умолчанию может стоять, например, Python 3.12. Если часть скриптов запускается через python3, а часть через python3.13, но обе используют один и тот же набор файлов/конфигов, получится прекрасный квест с непредсказуемым поведением.

💡 Решение:

чётко разделяй проекты по каталогам;
в каждом проекте своё venv и свои зависимости;
в документации проекта явно указывай версию Python и команду запуска.

Отсутствие документации

Часто кто-то «просто поставил Python и всё настроил», а через год никто не помнит:

какой PPA использовался;
где лежит venv;
какие пакеты критичны.

💡 Решение — минимальная документация:

файл README.md в корне проекта;
описание: какую версию Python использовать, как создать venv, как установить зависимости, как запускать сервис.

Мини‑шаг к продакшну: структура для сервиса

Чтобы статья была не только теоретической, покажу базовый скелет проекта для сервиса на Python 3.13.

~/projects/my_service/
├── venv/              # виртуальное окружение
├── app/
│   ├── __init__.py
│   └── main.py        # точка входа
├── requirements.txt
└── README.md

Пример простого main.py на FastAPI:

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
async def root():
    return {"status": "ok", "python": "3.13"}

Запуск внутри активированного venv:

uvicorn app.main:app --host 0.0.0.0 --port 8000

Дальше к этому легко прикрутить systemd‑юнит, Nginx в роли reverse‑proxy и мониторинг — но это уже темы для следующих статей.

Итоги

Мы аккуратно установили Python 3.13 на Ubuntu 24.04, не трогая системный интерпретатор, настроили pip и создали изолированное виртуальное окружение для проекта.

Ключевые мысли, которые стоит запомнить:

системный Python — не игрушка, его лучше не заменять;
для проектов всегда используем venv;
ставим пакеты через python3.13 -m pip, а не через «абстрактный» pip;
всё, что делаем на сервере, стараемся документировать.

С таким подходом Python 3.13 будет не «ещё один хаос в системе», а понятный, управляемый инструмент, с которым приятно работать и который не стыдно показать следующему администратору после тебя.