Окружения и зависимости: что делает venv, а что — pip

На чём проверено: CPython 3.11.15 и 3.12.3 (сборки Ubuntu), 3.13.7 и 3.14.7; linux/x86_64, bash; pip — тот, что ставит в свежее окружение ensurepip каждой версии. Документация и исходники сверены 14.10.2026. На эту дату вышел и Python 3.15 (9 октября 2026) — урок на нём не запускался.

База: зачем окружение и как его создают

Полный пример — команды для bash/zsh (POSIX: Linux, macOS); их можно выполнить по порядку в пустой папке, для установки из PyPI нужна сеть:

python3 -m venv env                          # создать окружение в папке env
source env/bin/activate                      # активировать (bash/zsh)
python -m pip install requests==2.32.3       # поставить пакет в окружение
python -m pip freeze > requirements.txt      # записать снимок установленного
deactivate                                   # выйти из окружения
python3 -m venv env2                         # создать второе, новое окружение
env2/bin/python -m pip install -r requirements.txt   # поставить в него по снимку

python -m pip, а не просто pip: так видно, каким интерпретатором — а значит, в какое окружение — ставится пакет. Последняя команда ставит пакеты во второе окружение без активации — по полному пути к его интерпретатору. На Windows папка скриптов окружения — Scripts, а не bin; активация по документации venv — env\Scripts\activate.bat в cmd.exe и env\Scripts\Activate.ps1 в PowerShell. Прогоны урока — только Linux и bash.

Ответ уровня Junior на «зачем виртуальное окружение»: чтобы у каждого проекта были свои версии пакетов, независимые от системы и других проектов; создают python -m venv, активируют activate, ставят пакеты pip, версии фиксируют в requirements.txt. Это верно, и за этим ответом идут уточнения: что такое окружение физически, обязательно ли его активировать, что именно делает activate и почему нельзя ставить пакеты в системный Python. Механизмы ниже отвечают на них прогоном.

Механизм 1: окружение — это папка и pyvenv.cfg

Вывод bench/venv/basics.py, раздел 1, CPython 3.13.7:

1) что внутри папки окружения (верхний уровень и bin/)
    ['.gitignore', 'bin', 'include', 'lib', 'lib64', 'pyvenv.cfg']
   bin/: ['Activate.ps1', 'pip', 'pip3', 'pip3.13', 'python', 'python3', 'python3.13'] + скрипты activate*
   bin/python — символическая ссылка: True -> <python>/bin/python3.13
   абсолютный путь окружения записан в bin/activate: True
   первая строка bin/pip: #!<папка>/env/bin/python3.13
   pyvenv.cfg:
      home = <python>/bin
      include-system-site-packages = false
      version = 3.13.7

Внутри окружения нет копии стандартной библиотеки: bin/python — ссылка на базовый интерпретатор, lib/…/site-packages — своя папка для пакетов (в свежем окружении в ней только pip), lib64 — ссылка на lib, а pyvenv.cfg записывает, откуда взят интерпретатор (home) и видны ли системные пакеты (include-system-site-packages = false — не видны).

Зато в окружении записаны абсолютные пути: в bin/activate и в первой строке bin/pip — по ней система выбирает, каким интерпретатором запустить скрипт. Что это значит, показывает копия окружения в другую папку той же машины. Вывод bench/venv/basics.py, раздел 6, CPython 3.13.7:

6) копия окружения в другую папку той же машины
   moved/bin/python: sys.prefix      -> <папка>/moved
   moved/bin/pip --version           -> <папка>/env/lib/python3.13/site-packages/pip
   moved/bin/python -m pip --version -> <папка>/moved/lib/python3.13/site-packages/pip
   без старой папки moved/bin/pip    -> FileNotFoundError: No such file or directory

Интерпретатор копии видит новую папку, а bin/pip по шебангу запускает интерпретатор старого окружения — и ставил бы пакеты туда. Без старой папки он не запускается вовсе. python -m pip работает с копией, но остальные скрипты из bin/ сломаны так же, как pip. На другой машине вдобавок home и ссылка bin/python указывают на установку Python, которой там может не быть. Поэтому окружение не переносят копированием: его пересоздают и ставят зависимости заново.

Механизм 2: как интерпретатор понимает, что он в окружении

Интерпретатор окружения запущен по пути, без активации. Вывод bench/venv/basics.py, раздел 2, CPython 3.13.7:

2) интерпретатор окружения, без активации
   sys.prefix               -> <папка>/env
   sys.base_prefix          -> <python>
   prefix != base_prefix    -> True
   куда ставятся пакеты     -> <папка>/env/lib/python3.13/site-packages

sys.prefix указывает на окружение, sys.base_prefix — на базовую установку, и пакеты ищутся и ставятся в site-packages окружения. Всё это решает сам интерпретатор по файлу pyvenv.cfg на уровень выше себя — в корне окружения. Отсюда практическое следствие: в cron, Dockerfile или systemd окружение не активируют — пишут полный путь env/bin/python script.py. Документация venv говорит то же: You don’t specifically need to activate a virtual environment, as you can just specify the full path to that environment’s Python interpreter when invoking Python (активировать окружение не обязательно: можно просто указать полный путь к интерпретатору окружения при запуске Python). А проверка «работаю ли я в окружении» из кода — sys.prefix != sys.base_prefix.

Кто именно ставит sys.prefix, зависит от версии: до 3.13 включительно — модуль site при старте интерпретатора, с 3.14 — инициализация путей, ещё до site. На обычный запуск это не влияет — раздел 2 прогона одинаков на 3.11–3.14. Разница видна только с ключом -S, который отключает site, — об этом в разделе «Глубже».

Механизм 3: изоляция пакетов и pip freeze

Вывод bench/venv/basics.py, разделы 3 и 4, CPython 3.13.7:

3) pip list в свежем окружении
    pip==25.2

4) изоляция: pip install tomli-w==1.0.0 в окружение
   интерпретатор окружения -> импортирован, версия 1.0.0
   базовый интерпретатор   -> ModuleNotFoundError: No module named 'tomli_w'
   у базового sys.prefix   -> <python>
   у базового пакеты в     -> <python>/lib/python3.13/site-packages
   Name в метаданных пакета -> tomli_w
   pip freeze              -> ['tomli_w==1.0.0']

В свежем окружении на 3.13 — только pip. Пакет, поставленный pip install в окружение, интерпретатор окружения импортирует, а базовый — нет: пакеты лежат в разных site-packages: у окружения — <папка>/env/lib/…, у базового — своя. Это и есть изоляция: проекты с разными версиями одной библиотеки живут на одной машине, не мешая друг другу и системе.

pip freeze печатает снимок установленного — в формате requirements, как сказано в описании команды: Output installed packages in requirements format (выводит установленные пакеты в формате requirements). Пакет из PyPI попадает в снимок строкой имя==версия, но так выглядят не все строки. В разделе 7 прогона в окружение дополнительно поставлены пакет из локальной папки и editable-пакет (pip install -e — установка ссылкой на папку с исходниками). Вывод bench/venv/basics.py, раздел 7, CPython 3.13.7:

7) pip freeze: что попадает в снимок
   python -m pip freeze:
      # Editable install with no version control (editpkg==0.1)
      -e <папка>/editpkg
      localpkg @ file://<папка>/localpkg
      tomli_w==1.0.0
   только в python -m pip freeze --all: ['pip==25.2']

Пакет из локальной папки записан прямой ссылкой (имя @ file://…), editable-пакет — строкой -e с путём; эти пути указывают на папки этой машины. Сам pip freeze пропускает, а --all его показывает. Что пропускать, решает pip по версии Python: до 3.11 включительно — pip, setuptools, distribute и wheel, с 3.12 — только pip (pip/_internal/commands/freeze.py, строки 12–20 в pip 24.0 из 3.11.15). В прогоне на 3.11 --all добавил pip==24.0 и setuptools==79.0.1.

Вывод freeze сохраняют в requirements.txt, чтобы python -m pip install -r requirements.txt в новом окружении поставил те же версии. Это сработает, если эти версии доступны для той платформы и версии Python; побайтно одинаковой сборки снимок не обещает — он хранит имена, версии и пути, а не сами файлы пакетов. pip сам отделяет freeze от lock-файла: pip freeze reports what is installed; it does not compute a lockfile or a solver result (pip freeze сообщает, что установлено; lock-файл или результат разрешения зависимостей он не вычисляет). Имя freeze печатает так, как оно записано в метаданных пакета, — там Name: tomli_w, — а не так, как его набрали в pip install tomli-w.

Механизм 4: что делает activate

Вывод bench/venv/basics.py, раздел 5, CPython 3.13.7, bash на Linux:

5) активация в bash: что она меняет
    VIRTUAL_ENV=<папка>/env
    VIRTUAL_ENV_PROMPT=env
    первый элемент PATH: <папка>/env/bin
    python в PATH: <папка>/env/bin/python
    после deactivate PATH прежний: да

activate — скрипт оболочки, а не часть Python. Для того, какой python найдётся, важен один PATH: env/bin встаёт в нём первым, и команды python и pip находят интерпретатор окружения. Кроме того, activate задаёт VIRTUAL_ENV и VIRTUAL_ENV_PROMPT, добавляет имя окружения в начало приглашения оболочки (PS1) и снимает PYTHONHOME, если она задана; deactivate всё это возвращает. Внутри интерпретатора активация ничего не меняет: если PYTHONHOME не задана, интерпретатор окружения работает одинаково, запущен ли он через PATH или по полному пути.

Это POSIX-вариант для bash/zsh; для fish и csh в bin/ лежат свои скрипты (activate.fish, activate.csh), а на Windows по документации venv — env\Scripts\activate.bat в cmd.exe и env\Scripts\Activate.ps1 в PowerShell. Прогон урока проверял только bash на Linux.

Глубже: что изменилось в окружениях

Сравнение прогонов на четырёх версиях показывает четыре изменения:

• 3.12: в свежем окружении нет setuptools. На 3.11 pip list в новом окружении — pip и setuptools, с 3.12 — только pip. Свежее окружение наполняет ensurepip, и набор задан в нём: на 3.11 _PACKAGE_NAMES = ('setuptools', 'pip'), на 3.12 — ('pip',). Проект, который неявно опирался на setuptools в окружении, на 3.12 должен объявить его зависимостью явно.
• 3.13: python -m venv кладёт в окружение .gitignore. Его содержимое cause the entire environment directory to be ignored by git (заставляет git игнорировать весь каталог окружения) — окружение не попадёт в репозиторий, даже если его забыли вписать в .gitignore проекта. Файл создаёт команда python -m venv, флаг --without-scm-ignore-files это отключает; venv.create() из кода по умолчанию его не создаёт.
• 3.14: sys.prefix окружения ставит инициализация путей, а не модуль site, и ключ -S его больше не сбрасывает. Подробно — ниже, после списка.
• 3.14: в bin/ есть ещё одно имя интерпретатора — 𝜋thon. Его добавляют только на 3.14 и только при кодировке файловой системы UTF-8; на работу окружения оно не влияет.

Версия pip в свежем окружении своя у каждого интерпретатора: в прогонах — 24.0 на 3.11 и 3.12, 25.2 на 3.13, 26.2.1 на 3.14. Её обновляют внутри окружения: python -m pip install --upgrade pip — или сразу при создании: python -m venv --upgrade-deps env. Для этого флага и нужен список CORE_VENV_DEPS в исходниках venv: на 3.11 — pip и setuptools, с 3.12 — pip.

Теперь о префиксе на 3.14. В документации site 3.14: site is no longer responsible for updating sys.prefix and sys.exec_prefix on Virtual Environments. This is now done during the path initialization (site больше не отвечает за то, чтобы выставить sys.prefix и sys.exec_prefix в виртуальных окружениях. Теперь это делается при инициализации путей) — и поэтому префиксы окружения больше не зависят от -S, ключа, который запускает интерпретатор без модуля site. Раздел 8 прогона — тот же env/bin/python, но с -S. Вывод bench/venv/basics.py, раздел 8, CPython 3.13.7:

8) env/bin/python -S: модуль site не импортируется
   sys.prefix               -> <python>
   sys.base_prefix          -> <python>
   prefix != base_prefix    -> False
   site в sys.modules       -> False
   site-packages в sys.path -> False

На 3.11 и 3.12 — то же: префикс окружения ставил site, и без него интерпретатор окружения считал себя базовой установкой. Тот же раздел на CPython 3.14.7:

8) env/bin/python -S: модуль site не импортируется
   sys.prefix               -> <папка>/env
   sys.base_prefix          -> <python>
   prefix != base_prefix    -> True
   site в sys.modules       -> False
   site-packages в sys.path -> False

Установка префикса и подключение site-packages теперь разделены: префикс ставит инициализация путей, а site-packages окружения в sys.path добавляет по-прежнему site, и при -S — последняя строка — их нет в sys.path ни на одной версии. Без -S разницы между версиями нет: раздел 2 прогона одинаков на 3.11–3.14, и прежнее объяснение «интерпретатор сам находит окружение по pyvenv.cfg» остаётся верным — на 3.14 меняется только то, какая часть интерпретатора это делает.

Как отвечать на собеседовании

Короткий ответ: виртуальное окружение — папка со своим интерпретатором и своим site-packages; создаётся python -m venv. Интерпретатор окружения находит его сам по pyvenv.cfg, а activate нужен оболочке — через PATH команда python находит интерпретатор окружения. Пакеты ставят python -m pip внутрь окружения, установленные версии записывают pip freeze в requirements.txt — это снимок установленного, а не lock-файл. В системный Python пакеты не ставят: окружение изолирует версии проектов.

Этого достаточно, чтобы ответить верно. Дальше — то, что добавляют, если собеседник копает.

Если интервьюер копает глубже

На «обязательно ли активировать окружение». «Нет. Интерпретатор env/bin/python сам ставит sys.prefix на окружение по pyvenv.cfg. В моём прогоне без активации sys.prefix != sys.base_prefix — True. В Docker и cron так и запускают — по полному пути».

На «что делает activate». «Главное — ставит env/bin первым в PATH, поэтому python и pip находят окружение. Ещё задаёт VIRTUAL_ENV и VIRTUAL_ENV_PROMPT, меняет приглашение оболочки и снимает PYTHONHOME; deactivate всё возвращает. Сам Python она не меняет — только переменные оболочки, которые он унаследует».

На «можно ли скопировать окружение на другую машину». «Нет. В bin/activate и в первой строке bin/pip записан абсолютный путь окружения. В моём прогоне даже в другой папке bin/pip копии запустил старое окружение, а без старой папки не запустился вовсе. На другой машине ещё и home в pyvenv.cfg и ссылка bin/python указывают на установку Python, которой там может не быть. Переносят список зависимостей — requirements.txt или lock-файл — и создают окружение заново, на совместимой платформе и версии Python».

На «чем pip freeze отличается от requirements.txt, написанного руками». «pip freeze печатает снимок всего установленного в формате requirements, с точными версиями, включая транзитивные зависимости, — кроме самого pip (на Python до 3.11 — ещё setuptools, wheel и distribute); editable- и локальные установки он пишет строками с путём. Руками обычно пишут только прямые зависимости. И это не lock-файл: pip прямо пишет, что freeze сообщает, что установлено, а lock-файл не вычисляет».

Дальше спросят

Частые заблуждения

История версий

Практика

Две задачи. Сначала ответьте, потом сверьтесь с настоящим выводом: в обеих правильный ответ взят из прогона скрипта, а не назначен.

import sys
print(sys.prefix == sys.base_prefix)
print(sys.prefix.endswith("env"))

False
True

True
False

True
True

False
False

Проверьте себя

Чем измерено

Наблюдения этого урока получены этими скриптами. Каждый открывается прямо отсюда — вместе с записью прогона: на чём запускали и что получилось.

• bench/venv/basics.py
• bench/venv/practice.py