Рабочее место: Python, окружение проекта и первый запуск

Зачем это нужно

Вчерашняя программа работала на голом Python: ничего ставить не пришлось. Но уже через несколько уроков нам понадобятся чужие библиотеки — для запросов, для таблиц, для графиков. И вот здесь новичка ждёт первая настоящая неприятность.

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

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

Сразу целиком

Всё, что ниже, — терминал. Наберите по строчке; знак $ набирать не надо, это приглашение оболочки.

$ python3 --version
Python 3.14.5

$ python3 -m venv .venv          # заводим окружение проекта
$ source .venv/bin/activate
$ python -c "import sys, pathlib; print(pathlib.Path(sys.executable).relative_to(pathlib.Path.cwd()))"
.venv/bin/python

$ python -c "import sys; print(sys.prefix == sys.base_prefix)"
False                            # мы внутри окружения

$ python -m pip install requests
Successfully installed certifi-2026.7.22 charset_normalizer-3.5.1 idna-3.19 requests-2.34.2 urllib3-2.7.0

$ python -c "import requests; print(requests.__version__)"
2.34.2

$ python -m pip freeze > requirements.txt
$ cat requirements.txt
certifi==2026.7.22
charset-normalizer==3.5.1
idna==3.19
requests==2.34.2
urllib3==2.7.0

$ deactivate                     # выходим из окружения
$ python3 -c "import sys; print(sys.prefix == sys.base_prefix)"
True                             # снова в системе
$ python3 -c "import requests"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
    import requests
ModuleNotFoundError: No module named 'requests'

$ printf '.venv/\n__pycache__/\n' > .gitignore
$ du -sh .venv
 17M    .venv

Номер патч-версии, версии библиотек и размер .venv у вас будут другими — они меняются каждый месяц. Важны не сами числа, а то, что происходит.

Если у вас Windows, часть команд выглядит иначе. Сами команды Python — те же; отличаются те, что обращаются к системе:

В PowerShell первая же активация может упереться в запрет на выполнение сценариев. Лечится один раз: Set-ExecutionPolicy -Scope CurrentUser RemoteSigned, и об этом сказано в документации venv.

Разбор

Сначала проверьте, что язык вообще есть

python3 --version — первая команда любого дня. Ответила номером — язык стоит. Ответила «command not found» — ставим:

• Windows: откройте python.org, скачайте установщик и обязательно отметьте галочку «Add python.exe to PATH» на первом экране. Забыли — переустановите, это быстрее, чем чинить.
• macOS: возьмите установщик с python.org — он не требует ничего ставить заранее. Если у вас уже есть Homebrew, то же самое делает brew install python. Тот Python, что пришёл с системой, лучше не трогать: им пользуется сама macOS.
• Linux: он почти наверняка уже есть; если нет — sudo apt install python3 python3-venv или то же через пакетный менеджер вашей системы.

Годится любая версия от 3.12: на 3.12 и 3.13 проверяется, что все программы курса компилируются. Написан и измерен курс на 3.14, и сообщения самого Python между версиями немного отличаются — если ваш вывод разошёлся с уроком в тексте ошибки, дело чаще всего в этом.

Что такое окружение и почему оно в папке проекта

python3 -m venv .venv создаёт папку .venv внутри проекта. Внутри — свой python и своё место для библиотек.

Строка .venv/bin/python в выводе это и подтверждает: после activate слово python означает не системный язык, а тот, что лежит в вашем проекте. Ничего не «настраивалось глобально» — просто изменился путь.

Образ. Своя аптечка в машине вместо общей на весь двор. В общей то кончится бинт, то кто-то положит просроченное; своя всегда такая, какой вы её собрали.

Доказательство, ради которого всё затевалось

Смотрите на две пары строк.

Первая пара — про то, где вы находитесь. sys.prefix — это папка, из которой работает интерпретатор, а sys.base_prefix — папка системного Python. Внутри окружения они разные, и сравнение даёт False; после deactivate — True. Это самая надёжная проверка: она не зависит ни от того, что у вас уже стоит, ни от приглашения оболочки.

Вторая пара — про библиотеку. Внутри окружения import requests работает, версия 2.34.2; снаружи тот же импорт даёт ModuleNotFoundError. Оговорка: если requests когда-то был поставлен в систему, снаружи импорт пройдёт — и это не значит, что окружение не работает. Смотрите тогда на первую проверку и на путь к python.

Это и есть изоляция: библиотека легла в проект, а не в систему. Сломать соседний проект теперь нечем.

requirements.txt — список, по которому окружение собирается заново

pip freeze печатает всё, что стоит в окружении, с точными версиями:

requests==2.34.2
urllib3==2.7.0

Мы сохранили это в requirements.txt. Через год, на другой машине, pip install -r requirements.txt соберёт то же самое. Обратите внимание: requests вы просили один, а список из пяти строк — остальное подтянулось за ним, и это нормально.

Сам .venv в репозиторий не кладут: 17 мегабайт, своя для каждой системы, и собирается по списку одной командой. Поэтому мы и завели .gitignore — тот самый, из двух строк:

.venv/
__pycache__/

Первая строка про окружение, вторая — про папку, которую Python создаёт сам, складывая туда скомпилированные модули.

Как теперь выглядит проект

$ ls -a
.gitignore .venv requirements.txt tsena.py 

$ source .venv/bin/activate
$ python tsena.py | head -5
== во сколько раз выросли цены в Казахстане
индекс цен 2010 года: 100.0
индекс цен 2025 года: 348.1
цены выросли в 3.48 раза
1000 тенге 2025 года = 287 тенге в ценах 2010 года

Четыре имени, и каждое на своём месте: код, список зависимостей, окружение и правило, что в репозиторий не едет. Вчерашняя программа запускается из проекта и печатает то же самое.

Дальше эта папка будет расти — в ней появятся модули, база и отчёт. Но структура заведена сегодня, и менять её не придётся.

Редактор

Подойдёт любой, но если выбираете — VS Code и расширение Python от Microsoft. Одна настройка важна: в правом нижнем углу выберите интерпретатор — тот, что в .venv. Тогда редактор будет подсказывать по тем библиотекам, которые действительно стоят у вас, а не по тем, что он выдумал.

Проверить просто: откройте tsena.py, нажмите «Run» — программа должна отработать так же, как из терминала.

Одно предупреждение про pip

Команду pip install вне окружения лучше не набирать никогда. И писать её лучше как python -m pip: так пакет гарантированно ставится тому интерпретатору, которым вы работаете, а не другому, который тоже нашёлся в системе. Если сомневаетесь, где вы, — посмотрите на приглашение: в активированном окружении слева стоит (.venv). Нет его — сначала source .venv/bin/activate (в Windows: .venv\Scripts\Activate.ps1).

Карта урока

Скажите своими словами

Не подглядывая, ответьте вслух или на бумаге. Ответы — в конце урока.

1. Что именно меняет activate, если ничего не устанавливается заново?
2. Почему .venv не хранят в репозитории, а requirements.txt — хранят?
3. Как за одну секунду понять, что вы находитесь вне окружения?

Разминка

Три коротких шага перед заданием. Сегодня они не про код, а про терминал: именно здесь новичок теряет вечер. Ответы — в конце урока.

1. Предскажите. Вы собрали окружение и не активировали его. Что покажет which python3 (в Windows — where python) и куда после этого попадёт pip install requests?

2. Заполните пропуск. Допишите три команды так, чтобы получился рабочий день с нуля:

python3 -m venv .venv
...
pip install -r requirements.txt

3. Почините. Человек жалуется: «поставил requests, а программа говорит ModuleNotFoundError». В приглашении терминала у него нет (.venv). Что произошло и что ему сделать?

Задание

Обязательное. Заведите папку digest, в ней окружение, перенесите туда вчерашнюю программу и запустите её из окружения. Затем поставьте в окружение requests и проверьте, что вы действительно в нём, а не где-то ещё:

import sys

print(sys.executable)                    # путь к питону, который вас слушает
print(sys.prefix != sys.base_prefix)     # True — вы в окружении

Выйдите из окружения (deactivate) и запустите те же две строки: путь изменится, а True станет False. Это и есть надёжная проверка. Проверять окружение попыткой импорта нельзя: requests вполне может оказаться установленным и в системе — тогда импорт сработает и снаружи, и вы сделаете неверный вывод.

По желанию.

• Посмотрите, что внутри .venv: ls .venv/lib/python3*/site-packages. Там лежат ровно те пять пакетов из списка.
• Удалите папку .venv целиком и соберите заново: python3 -m venv .venv && source .venv/bin/activate && pip install -r requirements.txt. Это и есть проверка того, что список полный.
• Заведите второй проект с другой версией requests и убедитесь, что первый от этого не изменился.

Куда это встанет в проекте

Сводка получила дом. Дальше всё, что мы пишем, живёт в папке digest: сегодня в ней одна программа и список зависимостей, к концу курса — модули, база, графики и отчёт.

Долги. Программа по-прежнему падает без интернета и берёт данные заново при каждом запуске. Мы ещё не сохраняем ничего на диск — а данные, которые получены, но не сохранены, приходится просить снова. Это ближайшие уроки.

Ответы

Источники

• Python: модуль venv
• Python: установка пакетов
• VS Code: работа с Python-окружениями