Глубокое введение в управление зависимостями

Добро пожаловать в один из самых критически важных уроков курса, посвященный виртуальным окружениям. На этапе 'Intermediate' вы перестаете писать изолированные скрипты, состоящие из одного файла, и начинаете создавать полноценные проекты. Эти проекты неизбежно требуют сторонних библиотек: requests для работы с сетью, Django для веб-разработки, pandas для анализа данных. И здесь возникает фундаментальная проблема: как управлять этими библиотеками?

Представьте ситуацию: вы разрабатываете проект 'А', который использует библиотеку Django версии 2.2. Через полгода вы начинаете новый проект 'Б', которому требуются новые функции из Django версии 4.2. По умолчанию, когда вы устанавливаете пакет через команду pip install django, Python помещает его в глобальное хранилище пакетов вашей операционной системы (так называемый каталог site-packages). Глобальное хранилище может содержать только одну версию конкретной библиотеки. Если вы обновите Django до версии 4.2 для проекта 'Б', ваш старый проект 'А' мгновенно сломается, так как между этими версиями существуют обратно несовместимые изменения.

Эта ситуация в индустрии программирования называется 'Dependency Hell' (Ад зависимостей). Более того, многие операционные системы на базе Linux (например, Ubuntu) используют Python для своих внутренних системных утилит (таких как пакетный менеджер apt). Если вы случайно обновите или удалите системную библиотеку, установив пакет глобально, вы можете буквально сломать свою операционную систему. Исторически разработчики часто сталкивались с ситуацией 'Works on my machine' (На моей машине все работает), когда код работал на компьютере создателя, но падал с ошибками на сервере из-за разных версий установленных пакетов.

Именно для решения этих критических проблем был придуман механизм Виртуальных окружений (Virtual Environments). Виртуальное окружение — это изолированная среда, в которой работает интерпретатор Python и в которой находится свой собственный, независимый от системы набор установленных библиотек. У каждого вашего проекта должно быть свое собственное виртуальное окружение. Это золотое правило Python-разработчика. В этом уроке мы разберем не только то, как использовать стандартный модуль venv, но и то, как он работает 'под капотом', как операционная система понимает, откуда брать библиотеки, и как избежать типичных ошибок новичков, связанных с путями и переменными окружения.

Анатомия виртуального окружения под капотом

Что же на самом деле представляет собой виртуальное окружение? Многие новички думают, что это какая-то сложная виртуальная машина или контейнер наподобие Docker. На самом деле всё гораздо проще и элегантнее. Виртуальное окружение в Python — это просто директория (папка) с определенной структурой внутри. Когда вы создаете виртуальное окружение с помощью встроенного модуля venv, Python не копирует весь интерпретатор (который может весить десятки мегабайт). Вместо этого он использует механизм символических ссылок (symlinks) или копирует лишь минимально необходимые бинарные файлы (в зависимости от вашей ОС).

Давайте заглянем внутрь этой директории. Обычно ее называют venv или .venv. Внутри вы найдете несколько ключевых элементов. Во-первых, директорию bin (на Linux/macOS) или Scripts (на Windows). Здесь лежат исполняемые файлы: сам интерпретатор python, пакетный менеджер pip, а также скрипты активации (например, activate, activate.bat, Activate.ps1). Во-вторых, директорию lib/python3.x/site-packages (или Lib\site-packages на Windows). Именно сюда будут устанавливаться все сторонние библиотеки, когда это окружение активно.

Но самый важный файл, который делает эту магию возможной — это конфигурационный файл pyvenv.cfg, расположенный в корне папки виртуального окружения. Этот файл содержит ключевую информацию. В нем указан путь к оригинальному ('базовому') интерпретатору Python в переменной home. Когда вы запускаете Python из виртуального окружения, он сканирует директорию на один уровень вверх от своего местоположения. Если он находит файл pyvenv.cfg, он понимает: 'Ага, я нахожусь в виртуальном окружении!'. После этого интерпретатор динамически меняет свои пути поиска пакетов (переменную sys.path), указывая на локальную папку site-packages вместо глобальной системной.

Также в pyvenv.cfg есть флаг include-system-site-packages = false. Если он установлен в 'false' (что происходит по умолчанию), ваше окружение полностью изолировано от системных библиотек. Если вы измените его на 'true', то если пакет не будет найден в локальном окружении, Python попробует поискать его в глобальной системе. В 99% случаев этот флаг должен оставаться 'false' для обеспечения чистой изоляции и строгой воспроизводимости (чтобы вы точно знали, какие библиотеки требует ваш проект).

Создание виртуального окружения: Шаг за шагом

Теперь, когда мы понимаем теорию, давайте перейдем к практике создания виртуальных окружений. Модуль venv встроен в стандартную библиотеку Python начиная с версии 3.3, что означает, что вам не нужно устанавливать никаких дополнительных инструментов (хотя на некоторых дистрибутивах Linux, таких как Ubuntu, вам может потребоваться установить пакет python3-venv через системный пакетный менеджер apt). Команда для создания виртуального окружения проста, но часто вызывает путаницу у новичков из-за своего синтаксиса.

Стандартная команда выглядит так: python -m venv название_папки. Давайте разберем её детально. Флаг -m означает 'run module as a script' (запустить модуль как скрипт). Мы говорим Python найти модуль venv в стандартной библиотеке и выполнить его. Следующий аргумент — это имя директории, которая будет создана для хранения окружения. В индустрии устоялся стандарт де-факто называть эту папку venv или .venv. Использование точки перед именем (.venv) делает папку скрытой на Unix-подобных системах (Linux и macOS), что удобно, так как она не засоряет вывод команды 'ls' в корне вашего проекта.

Пример идеального алгоритма действий для старта нового проекта: вы создаете папку для проекта (mkdir my_awesome_project), переходите в нее (cd my_awesome_project), и выполняете команду python -m venv venv. Обратите внимание, что слово 'venv' повторяется дважды: первое — это название модуля, второе — название создаваемой директории. Если в вашей системе установлено несколько версий Python, вы должны явно указать нужную версию при создании окружения. Например: python3.10 -m venv venv. Виртуальное окружение всегда жестко привязывается к той версии Python, которой оно было создано.

Симуляция Code Review (Junior vs Senior):
Junior: Я скопировал свою папку проекта вместе с папкой venv на другой компьютер (или залил в GitHub), но теперь ничего не работает, скрипты выдают ошибки путей!
Senior: Это классическая ошибка. Виртуальное окружение никогда нельзя копировать или перемещать, и оно обязательно должно быть добавлено в файл .gitignore. Папка venv содержит абсолютные пути (жестко прописанные пути к файлам на конкретном компьютере) в файлах активации и симлинках. При переносе на другую машину или даже в другую папку эти пути становятся недействительными. Правильный процесс: передавать только исходный код и файл со списком зависимостей (requirements.txt), а виртуальное окружение пересоздавать на новой машине с нуля.

Активация виртуального окружения: Магия переменной PATH

Создание окружения — это только половина дела. Чтобы ваш терминал начал использовать изолированный интерпретатор и локальные библиотеки, окружение необходимо активировать. Процесс активации отличается в зависимости от операционной системы и используемой оболочки командной строки (shell). На Windows это может быть Command Prompt (cmd.exe) или PowerShell. На Linux и macOS это чаще всего Bash или Zsh. Несмотря на разные команды, суть того, что происходит при активации, везде абсолютно одинакова.

Что именно делает команда активации? Главная задача скрипта активации — временно изменить глобальную переменную окружения операционной системы, которая называется PATH. Переменная PATH содержит список директорий, в которых ОС ищет исполняемые файлы, когда вы вводите команду в терминале. Когда вы пишете python, система просматривает папки из PATH слева направо, и выполняет первый найденный файл 'python.exe' (или 'python').

Скрипт активации берет абсолютный путь к папке bin (или Scripts) вашего виртуального окружения и помещает его в самое начало переменной PATH. Благодаря этому, когда вы после активации пишете команду python или pip, операционная система первым делом находит эти команды внутри вашего виртуального окружения, а не в глобальных системных папках. Именно так достигается эффект 'изоляции' на уровне командной строки.

Кроме того, скрипт активации модифицирует приглашение (prompt) командной строки, добавляя в начало имя виртуального окружения в скобках, например: (.venv) user@macbook:~/project$. Это визуальный индикатор того, что окружение активно. Важно понимать, что активация действует только для текущей сессии терминала. Если вы откроете новое окно терминала или закроете текущее, виртуальное окружение в новом окне не будет активно по умолчанию, и вам придется выполнить команду активации снова. Активация — это состояние конкретного окна консоли, а не глобальная настройка системы.

Особенности PowerShell в Windows и проблемы с правами

Для пользователей Windows, использующих современный терминал PowerShell (который является стандартом по умолчанию в VS Code и Windows 11), существует один классический подводный камень, о который спотыкается 95% новичков. Когда вы впервые пытаетесь выполнить скрипт активации .venv\Scripts\Activate.ps1, вы с высокой вероятностью получите красное сообщение об ошибке, гласящее: 'Невозможно загрузить файл ... так как выполнение сценариев отключено в этой системе' (Execution of scripts is disabled on this system).

Это не ошибка Python и не ошибка создания окружения. Это встроенная политика безопасности операционной системы Windows, которая называется Execution Policy. По умолчанию PowerShell запрещает выполнение любых скриптов (файлов с расширением .ps1), чтобы защитить пользователя от случайного запуска вредоносных программ, скачанных из интернета. Так как скрипт активации виртуального окружения — это тоже скрипт PowerShell, система блокирует его выполнение.

Чтобы решить эту проблему, вам необходимо единоразово изменить политику выполнения для вашего текущего пользователя. Для этого необходимо запустить PowerShell от имени администратора (нажать правой кнопкой мыши по иконке PowerShell в меню 'Пуск' и выбрать 'Запуск от имени администратора') и выполнить следующую команду: Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser. Разберем эту команду: мы меняем политику на RemoteSigned (это означает, что локальные скрипты, созданные на вашем компьютере, можно запускать без проблем, а скрипты, скачанные из интернета, должны иметь доверенную цифровую подпись). Флаг -Scope CurrentUser означает, что настройка применяется только к вашей учетной записи, что более безопасно, чем менять ее для всей системы (LocalMachine).

После успешного выполнения этой команды вам нужно подтвердить действие (нажать клавишу 'Y' или 'A'). Теперь вы можете закрыть терминал администратора, вернуться в свой обычный терминал в редакторе кода и без проблем активировать виртуальное окружение командой .\.venv\Scripts\Activate.ps1. Это действие нужно сделать только один раз на конкретном компьютере; в дальнейшем активация будет работать всегда.

Деактивация и проверка окружения

Когда вы закончили работу над проектом, вы можете выйти из виртуального окружения, вернув терминал в исходное состояние (восстановив оригинальную переменную PATH). Для этого используется команда deactivate. Обратите внимание, что эта команда одинакова для всех операционных систем и оболочек (Windows, macOS, Linux, Bash, PowerShell). Она не требует указания пути к скрипту, вы просто вводите слово deactivate прямо в консоль.

Как убедиться, что ваше виртуальное окружение действительно активно? Визуального префикса в виде (.venv) иногда бывает недостаточно, так как некоторые кастомные темы терминала (например, Oh My Zsh) могут его скрывать. В индустрии используют надежные команды для проверки.

На Linux и macOS используется команда which python. На Windows используется команда where python. Эти утилиты показывают полный путь к исполняемому файлу Python, который будет запущен при вводе команды. Если окружение активно, команда вернет путь, ведущий внутрь папки вашего проекта (например, /Users/name/projects/my_project/.venv/bin/python). Если окружение НЕ активно, команда вернет глобальный системный путь (например, /usr/bin/python3 или C:\Python310\python.exe).

Также хорошей практикой является проверка установленных пакетов. Если вы введете команду pip list в активированном чистом виртуальном окружении, вы увидите только два пакета: pip и setuptools. Это доказывает, что вы находитесь в 'чистой комнате'. Если же вы введете эту команду без активации окружения, вы, скорее всего, увидите длинный список всех библиотек, установленных в вашей системе глобально. Регулярная проверка путей с помощью which / where — это важнейший навык дебаггинга (отладки), который сэкономит вам часы поисков причины, почему 'модуль не найден', хотя вы только что его установили (вероятно, вы установили его в глобальную систему, забыв активировать venv).

Управление зависимостями: Инструмент pip

Виртуальное окружение само по себе — это просто пустая комната. Реальная польза начинается, когда мы заполняем эту комнату нужной нам мебелью — библиотеками. За установку и управление библиотеками в Python отвечает программа pip (аббревиатура от 'Pip Installs Packages' или 'Pip Installs Python'). Это официальный пакетный менеджер, который скачивает библиотеки из огромного центрального репозитория PyPI (Python Package Index — Индекс пакетов Python).

Главное правило: всегда используйте pip только при активированном виртуальном окружении. Если вы забудете активировать окружение, pip установит пакет глобально, загрязняя систему. Базовая команда установки выглядит просто: pip install имя_пакета. Например, pip install requests. pip автоматически свяжется с сервером PyPI, найдет последнюю стабильную версию библиотеки requests, скачает её, а также скачает все библиотеки, от которых зависит сам requests (так называемые транзитивные зависимости), и поместит их в папку site-packages вашего виртуального окружения.

Но что, если вам нужна конкретная версия библиотеки? Например, вы читаете старый туториал, где используется строго определенная версия. Для этого используются спецификаторы версий. Синтаксис pip install Django==3.2.19 (обратите внимание на двойное равно) установит ровно эту версию. Вы также можете использовать диапазоны версий: pip install "urllib3>=1.25.4,<1.27". Кавычки здесь важны, так как символы '<' и '>' могут быть восприняты командной оболочкой (терминалом) как операторы перенаправления ввода-вывода, что приведет к ошибке.

Помимо установки, pip умеет удалять пакеты (pip uninstall requests), обновлять их до последней версии (pip install --upgrade requests) и, что самое важное, показывать список всего, что установлено в текущем окружении (pip list). Если вы хотите получить более детальную информацию о конкретном пакете (кто его автор, где он находится на диске, от каких других пакетов он зависит), используйте команду pip show имя_пакета. Понимание работы pip — это фундамент создания стабильных приложений, так как несовпадение версий является причиной львиной доли багов на этапе интеграции кода.

Фиксация состояния: requirements.txt

Допустим, вы написали отличный парсер сайтов. Он использует библиотеки requests, beautifulsoup4 и lxml. Ваш проект лежит в папке, внутри которой есть папка .venv. Вы помните, что папку .venv нельзя копировать на другой компьютер и нельзя отправлять в Git. Как тогда ваш коллега, скачавший ваш код с GitHub, узнает, какие именно библиотеки и каких версий ему нужно установить, чтобы запустить ваш проект?

Здесь на сцену выходит концепция файла требований — requirements.txt. Это простой текстовый файл, в котором построчно перечислены все необходимые библиотеки и их точные версии. Вы можете создать этот файл вручную, но это долго и чревато ошибками (вы можете забыть транзитивные зависимости). Вместо этого pip предоставляет мощную команду: pip freeze. Эта команда работает так же, как pip list, но выводит список пакетов в формате, который идеально подходит для файла требований, используя оператор '=='.

Чтобы сохранить этот список в файл, мы используем оператор перенаправления вывода командной строки '>'. Команда pip freeze > requirements.txt возьмет весь вывод команды freeze и запишет его в текстовый файл с указанным именем в текущей директории. Теперь этот текстовый файл обязательно нужно закоммитить в систему контроля версий (Git). Он станет своеобразным 'рецептом' или 'чертежом' вашего проекта.

Когда ваш коллега (или вы сами на другом компьютере, или сервер автоматического развертывания) скачает код, процесс восстановления рабочего окружения будет следующим: 1) Создать новое, пустое виртуальное окружение. 2) Активировать его. 3) Выполнить команду pip install -r requirements.txt. Флаг '-r' означает 'read' (прочитать) из файла. pip прочитает файл построчно и установит все указанные библиотеки ровно тех версий, которые там прописаны. Таким образом, вы достигаете 100% воспроизводимости среды (reproducibility) — важнейшего критерия профессиональной разработки программного обеспечения.

Интеграция с редакторами кода: VS Code и PyCharm

Виртуальные окружения — это стандарт индустрии, поэтому все современные интегрированные среды разработки (IDE) и продвинутые редакторы кода имеют встроенную поддержку для работы с ними. Однако IDE часто 'теряет' виртуальное окружение, если вы создали его неправильно или в нестандартном месте. Понимание того, как ваш редактор взаимодействует с venv, сэкономит вам массу нервов, особенно когда редактор подчеркивает красным ваш импорт (например, import requests), хотя вы точно знаете, что установили библиотеку.

Visual Studio Code (VS Code): У VS Code есть мощное расширение для Python от Microsoft. Когда вы открываете папку проекта в VS Code, расширение сканирует корневую директорию на наличие папок с названиями venv, .venv, env. Если оно находит виртуальное окружение, оно обычно автоматически предлагает выбрать его в качестве интерпретатора по умолчанию для этого рабочего пространства. Вы можете выбрать интерпретатор вручную, открыв Command Palette (Ctrl+Shift+P или Cmd+Shift+P) и введя 'Python: Select Interpreter'. Там вы увидите список всех найденных версий Python на компьютере, включая ваше локальное окружение. Если вы выберете его, то при открытии встроенного терминала VS Code автоматически активирует это окружение за вас.

PyCharm: Эта IDE от JetBrains имеет более строгий, проприетарный подход к окружениям. По умолчанию, когда вы создаете новый проект в PyCharm, он сам автоматически создает виртуальное окружение (venv) для вас, часто скрывая консольные команды под капотом графического интерфейса. Вы можете управлять окружением через меню: File -> Settings -> Project -> Python Interpreter (на macOS: PyCharm -> Preferences). Там вы можете визуально добавлять пакеты (через кнопку '+') без использования консольного pip. Однако, умение работать с консолью критически важно, так как на сервере или в системе непрерывной интеграции (CI/CD) у вас не будет PyCharm, только командная строка.

Важный момент: если ваш редактор не 'видит' библиотеки, проблема в 99% случаев заключается в том, что редактор использует глобальный системный интерпретатор Python, а не тот, который находится в папке .venv/bin/python вашего проекта. Вам нужно явно указать редактору путь к интерпретатору внутри вашего виртуального окружения.

Продвинутое управление: Проблемы pip freeze и pip-tools

До сих пор мы рассматривали классический, базовый подход к управлению зависимостями. Однако у команды pip freeze > requirements.txt есть существенный архитектурный недостаток для крупных проектов. Суть проблемы в следующем: эта команда сваливает в один файл абсолютно всё, что установлено в окружении. Она не делает различий между 'прямыми' зависимостями (библиотеками, которые вы явно установили, например requests) и 'транзитивными' зависимостями (библиотеками, которые установились сами, потому что они нужны для работы requests, например urllib3 и certifi).

Представьте, что через год вы захотите обновить пакет в вашем проекте, или удалить библиотеку. Если вы смотрите в requirements.txt, сгенерированный через pip freeze, вы увидите там список из 50 пакетов. Вы не сможете вспомнить, какие из них добавили вы, а какие установились автоматически как зависимости. Удаление 'главного' пакета оставит в системе мусорные пакеты зависимостей, так как pip по умолчанию не удаляет транзитивные зависимости.

Для решения этой проблемы в современной Python-разработке (уровня Middle/Senior) часто используют инструмент pip-tools. Этот подход подразумевает создание файла requirements.in (вручную), в который вы вписываете только прямые зависимости (например, просто слово requests без жесткой версии). Затем вы запускаете утилиту pip-compile из набора pip-tools. Она анализирует ваш requirements.in, разрешает все транзитивные зависимости, находит совместимые версии и автоматически генерирует для вас подробный файл requirements.txt с комментариями, указывающими, откуда взялся каждый транзитивный пакет.

Затем, для установки пакетов из этого сгенерированного файла, используется команда pip-sync. Она не только устанавливает недостающие пакеты, но и удаляет из окружения те пакеты, которых больше нет в requirements.txt. Это гарантирует идеальную чистоту вашего виртуального окружения и исключает накопление 'мусора' (осиротевших зависимостей) со временем. Знание таких инструментов отличает уверенного разработчика от новичка.

Альтернативные менеджеры: Poetry и Pipenv

Модуль venv и утилита pip — это классика и стандарт стандартной библиотеки. Вы обязаны знать их, так как они используются в большинстве существующих проектов, в туториалах и в CI/CD пайплайнах. Однако, экосистема Python не стоит на месте. Со временем сообщество поняло, что связка venv+pip+requirements.txt имеет ограничения (например, отсутствие автоматического разрешения конфликтов версий и разделения на зависимости для разработки и продакшена).

Из-за этого появились современные сторонние инструменты, которые пытаются объединить создание виртуального окружения и управление пакетами в одну удобную команду (подобно npm в JavaScript или cargo в Rust). Два самых популярных инструмента на сегодняшний день — это Poetry и Pipenv.

Poetry: Стал невероятно популярен в последние годы. Он использует файл конфигурации pyproject.toml (новый стандарт для Python-проектов, описанный в PEP 518) вместо requirements.txt. Poetry сам создает виртуальное окружение, когда вы устанавливаете пакет (например, poetry add requests). Он создает файл блокировки poetry.lock, который фиксирует абсолютно все транзитивные зависимости с хэшами безопасности (гарантируя математически точную воспроизводимость на любом сервере). Он также решает конфликты зависимостей: если пакет A требует библиотеку C версии 1.0, а пакет B требует библиотеку C версии 2.0, Poetry выдаст понятную ошибку и откажется ломать окружение (тогда как старые версии pip могли молча перезаписать пакет).

Несмотря на мощь этих инструментов, путь новичка должен начинаться с 'голого' venv и pip. Изучение Poetry до понимания того, как работает переменная PATH, что такое site-packages и как активируются окружения — это путь к фундаментальному непониманию происходящего под капотом, что приведет к ступору при первой же серьезной ошибке на сервере. Считайте venv 'механической коробкой передач', а Poetry — 'автоматом'. Сначала нужно научиться чувствовать сцепление.

Типичные ошибки и Troubleshooting (Отладка)

Работа с виртуальными окружениями порождает множество типичных ошибок, которые мы сейчас разберем. Это знания, добытые кровью и потраченным временем поколений разработчиков. Внимательно изучите эти ситуации, это своеобразный тренажер (Active Recall) для вашего понимания.

Ситуация 1: 'Я установил библиотеку через pip, но код выдает ModuleNotFoundError'. Причина: вы забыли активировать виртуальное окружение перед запуском pip install. Пакет установился в глобальную систему. Затем вы запустили код внутри виртуального окружения (или из IDE, которая использует venv), и он, будучи изолированным, не видит глобальных пакетов. Решение: активируйте окружение в консоли и установите пакет заново.

Ситуация 2: 'Команда python не распознана или не найдена'. Это часто случается в Windows при неправильной установке Python (вы не поставили галочку 'Add Python to PATH' в установщике). Система вообще не знает, где находится базовый интерпретатор, поэтому команда python -m venv не работает. Решение: переустановить Python с нужной галочкой или использовать полные пути к интерпретатору.

Ситуация 3: Загрязнение репозитория. 'Я сделал git push, и мой коммит весит 500 МБ!'. Причина: вы не добавили папку .venv в файл .gitignore, и Git закоммитил тысячи файлов сторонних библиотек и бинарники интерпретатора. Решение: нужно удалить папку из Git (используя команду git rm -r --cached .venv), добавить её в .gitignore и сделать новый коммит. Никогда не отправляйте venv в систему контроля версий!

Ситуация 4: Проблемы с sudo (на Linux/macOS). 'pip выдал ошибку Permission denied, я использовал sudo pip install'. Это катастрофическая ошибка! Использование sudo запускает pip с правами суперпользователя системы. Во-первых, это сломает изоляцию вашего виртуального окружения (пакеты установятся глобально с правами root). Во-вторых, выполнение скриптов пакета (setup.py) от сторонних разработчиков с правами root — это огромная дыра в безопасности. Решение: никогда не используйте sudo вместе с pip. Если вам нужны права, значит вы не активировали виртуальное окружение (так как в своей папке venv у вашего обычного пользователя есть полные права на запись).

Заключение и лучшие практики (Best Practices)

Подведем итог нашему масштабному исследованию виртуальных окружений. Умение грамотно управлять зависимостями — это то, что отличает профессионального инженера-программиста от любителя. Ваш проект должен быть надежным, переносимым и легко разворачиваемым. Для этого нужно выработать определенные привычки, доведенные до автоматизма.

Чек-лист создания любого нового Python-проекта:
1. Создали директорию для проекта.
2. Инициализировали Git (git init).
3. Создали файл .gitignore и сразу вписали туда .venv/ (и __pycache__/).
4. Создали виртуальное окружение: python -m venv .venv.
5. Активировали его: source .venv/bin/activate (или скрипт для Windows).
6. Обновили встроенный пакетный менеджер (хорошая практика): pip install --upgrade pip.
7. Начали устанавливать нужные библиотеки (например, pip install fastapi).
8. Зафиксировали зависимости: pip freeze > requirements.txt.
9. Выбрали интерпретатор в вашем редакторе кода (VS Code / PyCharm), указав на созданный venv.

Применяя эти шаги, вы гарантируете, что ваш проект будет работать стабильно. Вы не столкнетесь с конфликтами версий. Если ваш жесткий диск сгорит, вы легко восстановите проект на новом ноутбуке: сделаете git clone вашего репозитория, создадите новый venv, и одной командой 'pip install -r requirements.txt' вернете систему в 100% рабочее состояние за пару минут. Понимание философии изоляции — это ваш пропуск в мир сложной, командной и коммерческой разработки, где над одним кодом трудятся десятки людей, а приложения разворачиваются на сотнях серверов с помощью CI/CD пайплайнов.