Проєкт «Афіша» потребує бібліотеку zvitnyk 1.4, проєкт «Звіти» — ту саму бібліотеку версії 2.0. Обидва запускаються системним python3, без віртуальних середовищ. Що станеться після pip install zvitnyk==2.0.0?
Чому так. У теці site-packages лежить рівно одна тека з іменем zvitnyk, бо import шукає модуль за іменем. Друге встановлення просто затирає перше — тому в інтерактиві 1 лічильник «працює проєктів» ніколи не піднімався вище 1 з 2. Конфлікту pip тут не бачить: із його погляду це звичайне оновлення.
Питання 2 / 8
Що саме робить команда активації середовища (source .venv/bin/activate)?
Чому так. Активація — це три дрібниці в оболонці, і жодна з них не чіпає сам Python. Саме тому вона не обовʼязкова: пряма команда .venv/bin/python zvit.py дає той самий результат без жодної активації. Ніякого «режиму» в інтерпретатора не існує.
Питання 3 / 8
Ти запустила .venv/bin/python і надрукувала sys.path. Що там буде?
Чому так. Перші рядки sys.path однакові в обох випадках — стандартна бібліотека береться з базового Python, на який вказує рядок home у pyvenv.cfg. Змінюється тільки хвіст списку: замість системного site-packages там тека проєкту. Системний у список не потрапляє взагалі — якщо тільки середовище не створене з прапорцем --system-site-packages.
Питання 4 / 8
У requirements.txt написано zvitnyk~=1.4.2. Автор бібліотеки випустив 1.4.9, 1.5.0 і 2.0.0. Яку версію поставить pip?
Чому так. У записі ~=1.4.2 три числа, тому мінятися може лише третє: діапазон дорівнює >=1.4.2,<1.5.0. Якби було написано ~=1.4 (два числа), рости могло б друге, і pip узяв би 1.7.3. Серед усіх відповідних версій pip завжди бере найновішу — тому 1.4.9, а не 1.4.2.
Питання 5 / 8
Колега клонує проєкт через пів року. У requirements.txt рядок написано просто як zvitnyk, без версії. Код проєкту не змінювався. Що найімовірніше станеться?
Чому так. Рядок без обмеження означає «будь-яка версія», а серед усіх відповідних pip бере найновішу — тобто результат залежить від дати встановлення. Найнеприємніше тут те, що баг відкладений: файл поводиться бездоганно, доки автор бібліотеки не випустить наступну велику версію, і зламається не той, хто писав файл.
Питання 6 / 8
На свіжому Ubuntu команда pip install requests відповідає error: externally-managed-environment. Яка реакція правильна?
Чому так. Це не поломка, а захист PEP 668: частина ОС написана на Python, і pip, перезаписуючи системну бібліотеку, ламає менеджер пакетів. sudo тут не допоможе (маркер зупинить pip незалежно від прав) і зробить гірше, а --break-system-packages назвали чесно — він описує наслідок, а не дозвіл. Для утиліт командного рядка є ще pipx, який робить те саме середовище автоматично.
Питання 7 / 8
Чому теку .venv не додають у git-репозиторій?
Чому так. Середовище повністю відновлюється з requirements.txt однією командою — зберігати те, що обчислюється, безглуздо. До того ж усередині записані абсолютні шляхи твоєї машини й скомпільовані файли під конкретну ОС (.so проти .pyd). У репозиторій кладуть кілька сотень байтів requirements.txt замість сотень мегабайтів теки.
Питання 8 / 8
У чому головна різниця між requirements.txt, згенерованим через pip freeze, і секцією dependencies у pyproject.toml?
Чому так. pip freeze відповідає на питання «що зараз стоїть у мене»: там будуть і випадкові пакети, і залежності залежностей із жорсткими ==. pyproject.toml відповідає на питання «чим є цей проєкт» і зазвичай містить діапазони. Обидва файли живуть поруч без конфлікту, і pyproject.toml розуміє не тільки pip, а й складальники, лінтери й форматувальники.