Secure installs | pip documentation
Фіксує безпечніші pip installs через pinned requirements, hashes і binary distributions.
Навіщо встановлювати Playwright-браузери, як часто та чому треба оновлювати бібліотеки → Першоджерело ↗Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Терміни, нюанси та джерела
hash-checking mode
Режим pip --require-hashes, у якому requirements мають бути pinned і містити hashes для всіх прямих та транзитивних залежностей.
Навіщо встановлювати Playwright-браузери, як часто та чому треба оновлювати бібліотеки →IDE install action не перевіряє довіру
pip documentation прямо попереджає, що installation може виконувати arbitrary code з distributions. Назву й джерело package потрібно перевіряти до install; для repeatable secure installs доступний hash-checking mode.
Навіщо встановлювати Playwright-браузери, як часто та чому треба оновлювати бібліотеки →Мінімальний CI setup для Chromium
Команди відокремлюють Python dependencies, сумісний Chromium із системними бібліотеками та сам test run.
CI runner має потрібний Chromium і запускає pytest suite.
Навіщо встановлювати Playwright-браузери, як часто та чому треба оновлювати бібліотеки →pip Requirements File Format
Підтверджує research-уточнення цього уроку.
Як працює проєктний білдер, ізоляція залежностей і впровадження нових інструментів → Першоджерело ↗Відтворюване локальне середовище
Команди створюють ізольоване середовище та встановлюють описані залежності; однаковий resolved graph потребує окремої lock-стратегії.
Створено .venv і встановлено залежності з requirements.txt.
Як працює проєктний білдер, ізоляція залежностей і впровадження нових інструментів →Чим uv відрізняється від pip
pip — базовий і простий інструмент, тоді як uv дає швидше встановлення, сучасніше керування проєктом і зручніші механізми для команд запуску та конфігурації. uv написаний на Rust і особливо помітно скорочує час відновлення залежностей у CI та після клонування репозиторію. Окрема перевага — робота з конфліктами транзитивних залежностей, коли дві бібліотеки очікують різні версії третьої. uv також дає чіткіший контроль за правилами оновлення й фіксації версій. Аналогія з Java: Maven виконує базову задачу, Gradle надає ширші можливості й за коректної конфігурації може швидше збирати проєкт. Але переваги нового інструмента треба пов’язувати з реальною проблемою команди, а не лише з його новизною.
Поступове впровадження нового інструмента
Переписувати весь test suite з нуля зазвичай не потрібно. Коли старий тест зламався або нову задачу значно легше реалізувати новим засобом, її можна зробити на uv чи Playwright і залишити робочі старі тести на pip або Selenium. В одному репозиторії тимчасово можуть співіснувати: - pip і uv; - Maven і Gradle; - Selenium і Playwright; - pytest та інший test runner; - JUnit і TestNG. CI просто виконує окремі команди для відповідних наборів. Основний ризик — не саме співіснування, а конфлікти спільних транзитивних залежностей і додаткова вартість підтримки двох стеків. Найбезпечніший аргумент для міграції — конкретна користь на конкретному сценарії: швидше встановлення, простіша діагностика, потрібне мокання network або стабільніша робота з браузером. Після доказу підхід можна розширювати.
Локальні пакети й ізоляція проєктів
Мови й екосистеми мають власні package managers або build tools: pip, npm, Maven, Gradle та інші. Вони завантажують бібліотеки з центральних репозиторіїв і можуть кешувати їх локально, але залежності конкретного проєкту визначаються окремо. Python virtual environment ізолює бібліотеки одного проєкту від іншого. На одному комп’ютері можуть співіснувати робочі й особисті репозиторії з різними версіями Playwright, pytest та інших пакетів. Конфлікт можливий, якщо запустити код не тим глобальним Python або неправильно вибрати interpreter. Самі залежності коректно створених `venv` не повинні впливати на сусідні проєкти.
Базова технічна самостійність middle engineer
Middle має володіти мовою настільки, щоб писати й підтримувати UI та API tests, а також пояснити, як перевірити нову поведінку й які наявні тести варто змінити. UI automation легше показує зв'язок із діями користувача, тоді як API automation часто швидша й стабільніша, але вимагає впевнено працювати з більшими структурами даних і контрактами. Очікується знання базових типів, перетворень і наслідків звуження/розширення типів, dependency/build tool свого stack (`requirements.txt`, `pip`/`uv`, Maven/Gradle, npm), а також можливостей test runner. Важливо вміти запустити тести паралельно й розуміти, які ресурси та змінні створюються для кожного worker.
Пакет Playwright і браузери — різні артефакти
`pip install` за `requirements.txt` встановлює Python-бібліотеку Playwright, але не гарантовано завантажує сумісні браузерні binaries. Тому після клонування проєкту окремо запускають `playwright install` або, для меншого завантаження, команду з потрібним браузером, наприклад `playwright install chromium`. Playwright керує власними сумісними збірками Chromium, Firefox і WebKit. Якщо потрібної збірки немає у його cache, запуск завершується помилкою навіть тоді, коли сам Python-пакет уже встановлений.
`requirements.txt` і транзитивні залежності
Щоб проєкт можна було клонувати й запустити на іншій машині, його прямі залежності фіксують у конфігурації на кшталт `requirements.txt`. Бібліотеки самі залежать від інших пакетів — це транзитивні залежності. Повний freeze може додати до файлу весь граф пакетів. Автор радить не зберігати зайвий шум без потреби: достатньо явно вказати основні залежності, наприклад Playwright і pytest, а їхні сумісні внутрішні пакети підтягнуться автоматично. Жорстко фіксувати весь граф варто тоді, коли відтворюваність або конфлікти версій справді стали проблемою. Інакше довгий список складніше підтримувати й аналізувати.
Сучасний інструмент чи фундаментальні основи
Poetry названо сучаснішим і декларативнішим за pip, хоча uv має перевагу у швидкості та простоті. Однозначної відповіді, з чого починати навчання, немає. Прості інструменти краще показують базову механіку, а сучасні швидше дають продуктивний результат. Збалансований шлях — працювати сучасним стеком, але паралельно досліджувати, що відбувається під капотом і які проблеми він вирішує. Розуміння внутрішньої механіки зменшує кількість випадкових workaround і допомагає помічати нові можливості бібліотек замість того, щоб будувати власні обхідні рішення.