Secure installs | pip documentation
Фіксує безпечніші pip installs через pinned requirements, hashes і binary distributions.
Навіщо встановлювати Playwright-браузери, як часто та чому треба оновлювати бібліотеки → Першоджерело ↗Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Фіксує безпечніші pip installs через pinned requirements, hashes і binary distributions.
Навіщо встановлювати Playwright-браузери, як часто та чому треба оновлювати бібліотеки → Першоджерело ↗Поточний installation guide показує uv add pytest-playwright як підтриманий варіант поряд із pip і Poetry; це додатковий workflow, а не вимога переписувати урок.
Режим pip --require-hashes, у якому requirements мають бути pinned і містити hashes для всіх прямих та транзитивних залежностей.
Навіщо встановлювати Playwright-браузери, як часто та чому треба оновлювати бібліотеки →pip documentation прямо попереджає, що installation може виконувати arbitrary code з distributions. Назву й джерело package потрібно перевіряти до install; для repeatable secure installs доступний hash-checking mode.
Навіщо встановлювати Playwright-браузери, як часто та чому треба оновлювати бібліотеки →Команди відокремлюють Python dependencies, сумісний Chromium із системними бібліотеками та сам test run.
CI runner має потрібний Chromium і запускає pytest suite.
Навіщо встановлювати Playwright-браузери, як часто та чому треба оновлювати бібліотеки →Підтверджує research-уточнення цього уроку.
Як працює проєктний білдер, ізоляція залежностей і впровадження нових інструментів → Першоджерело ↗У PyCharm можна ввімкнути CamelHumps/Camel Words, щоб навігація й виділення працювали за частинами `snake_case` та інших складених імен. Для відтворення середовища на іншому комп’ютері або CI версії залежностей фіксуються у `requirements.txt`: ```bash pip freeze > requirements.txt pip install -r requirements.txt ``` `pip freeze` записує також транзитивні бібліотеки. Автор показує, що список можна звести до прямих залежностей із зафіксованими версіями, якщо команда свідомо підтримує такий формат.
pip — базовий і простий інструмент, тоді як uv дає швидше встановлення, сучасніше керування проєктом і зручніші механізми для команд запуску та конфігурації. uv написаний на Rust і особливо помітно скорочує час відновлення залежностей у CI та після клонування репозиторію. Окрема перевага — робота з конфліктами транзитивних залежностей, коли дві бібліотеки очікують різні версії третьої. uv також дає чіткіший контроль за правилами оновлення й фіксації версій. Аналогія з Java: Maven виконує базову задачу, Gradle надає ширші можливості й за коректної конфігурації може швидше збирати проєкт. Але переваги нового інструмента треба пов’язувати з реальною проблемою команди, а не лише з його новизною.
PyCharm зазвичай створює для нового Python-проєкту окреме віртуальне середовище `.venv`. Воно ізолює версію Python і бібліотеки конкретного проєкту від інших проєктів на комп’ютері. У вбудованому терміналі активне середовище позначається префіксом на кшталт `(.venv)`. Термінал можна відкрити через меню дій або гарячою клавішею (`Option+F12` на macOS чи `Alt+F12` у відповідній розкладці на Windows). Для інтеграції Playwright із pytest встановлюється пакет: ```bash pip install pytest-playwright ``` Плагін надає готові pytest-фікстури, зокрема `page`, і бере на себе створення браузера, контексту та сторінки для тесту.
Переписувати весь test suite з нуля зазвичай не потрібно. Коли старий тест зламався або нову задачу значно легше реалізувати новим засобом, її можна зробити на uv чи Playwright і залишити робочі старі тести на pip або Selenium. В одному репозиторії тимчасово можуть співіснувати: - pip і uv; - Maven і Gradle; - Selenium і Playwright; - pytest та інший test runner; - JUnit і TestNG. CI просто виконує окремі команди для відповідних наборів. Основний ризик — не саме співіснування, а конфлікти спільних транзитивних залежностей і додаткова вартість підтримки двох стеків. Найбезпечніший аргумент для міграції — конкретна користь на конкретному сценарії: швидше встановлення, простіша діагностика, потрібне мокання network або стабільніша робота з браузером. Після доказу підхід можна розширювати.
Замість ручної послідовності створення `venv`, активації та `pip install -r requirements.txt` проєкт переходить на `uv sync`. Залежності й метадані описуються у `pyproject.toml`, а `uv.lock` фіксує точні версії, включно з транзитивними залежностями. Для застосунку або тестового проєкту lock-файл варто комітити: це відтворює однаковий dependency graph локально та в CI й зменшує ризик конфліктів, коли різні бібліотеки вимагають несумісні версії спільної залежності.
Мови й екосистеми мають власні package managers або build tools: pip, npm, Maven, Gradle та інші. Вони завантажують бібліотеки з центральних репозиторіїв і можуть кешувати їх локально, але залежності конкретного проєкту визначаються окремо. Python virtual environment ізолює бібліотеки одного проєкту від іншого. На одному комп’ютері можуть співіснувати робочі й особисті репозиторії з різними версіями Playwright, pytest та інших пакетів. Конфлікт можливий, якщо запустити код не тим глобальним Python або неправильно вибрати interpreter. Самі залежності коректно створених `venv` не повинні впливати на сусідні проєкти.
Selenium розглядається не як одна функція для керування браузером, а як екосистема. Для Python-тестів ключовим є Selenium WebDriver; Selenium IDE дає змогу записати простий сценарій у браузері й згенерувати початковий код, а Grid стосується розподіленого запуску. Залежність додається через `pip install selenium` або `uv add selenium`, після чого середовище треба синхронізувати. Допоміжний `pytest-selenium` може спростити старт, але урок застерігає від прив’язки до слабо підтримуваної обгортки: базову Selenium fixture нескладно контролювати самостійно. `pytest` залишається test runner незалежно від браузерної бібліотеки. Тому Selenium- і Playwright-тести можуть певний час співіснувати в одному Python-проєкті під час поступової міграції; їх достатньо розвести по зрозумілих packages, не переписуючи весь набір одразу.
Middle має володіти мовою настільки, щоб писати й підтримувати UI та API tests, а також пояснити, як перевірити нову поведінку й які наявні тести варто змінити. UI automation легше показує зв'язок із діями користувача, тоді як API automation часто швидша й стабільніша, але вимагає впевнено працювати з більшими структурами даних і контрактами. Очікується знання базових типів, перетворень і наслідків звуження/розширення типів, dependency/build tool свого stack (`requirements.txt`, `pip`/`uv`, Maven/Gradle, npm), а також можливостей test runner. Важливо вміти запустити тести паралельно й розуміти, які ресурси та змінні створюються для кожного worker.
`pip install` за `requirements.txt` встановлює Python-бібліотеку Playwright, але не гарантовано завантажує сумісні браузерні binaries. Тому після клонування проєкту окремо запускають `playwright install` або, для меншого завантаження, команду з потрібним браузером, наприклад `playwright install chromium`. Playwright керує власними сумісними збірками Chromium, Firefox і WebKit. Якщо потрібної збірки немає у його cache, запуск завершується помилкою навіть тоді, коли сам Python-пакет уже встановлений.
У документації Playwright потрібно завжди перевіряти обрану мову: приклади для Node.js, Python, Java та .NET відрізняються. Після встановлення залежностей варто прочитати вивід `pip` і перевірити список пакетів у Python Interpreter. Окрім `playwright` і `pytest`, там з’являться їхні транзитивні залежності.