🐍 Python · 20 вопросов · ~50 мин · ⏱ Таймер 50:00 · Средний ·

Виртуальные окружения и зависимости

Учит изолировать проект, фиксировать версии, понимать конфликты и воспроизводить установку. Вопросы построены на командах, ограничениях версий и сценариях сборки: нужно отличать состояние конкретного окружения от намерений проекта и выбирать воспроизводимый способ выпуска. Все задания рассчитаны на CPython 3.12; отличия других реализаций или версий учитываются только там, где это прямо оговорено.

Отвечено: 0 из 20

⏱ --:--

💡 Инструкция: Версия: CPython 3.12. Выберите один ответ из четырёх. На 20 вопросов отведено не меньше 40 минут; сопоставляйте команды с состоянием окружения и последствиями для воспроизводимости. После завершения вы увидите общий процент, четыре тематические шкалы и объяснение каждого ответа.

Вопрос 1 из 20

Проследите два пути в выводе команд: как определить, что `pip` относится именно к запускаемому интерпретатору?

Путь из `sys.executable` следует сопоставить с `python -m pip --version` Достаточно посмотреть имя активной папки в приглашении оболочки Сравнить только номер версии `pip` и номер версии Python Посмотреть путь команды `pip`, не сверяя его с запускаемым Python

Вопрос 2 из 20

Что даёт виртуальное окружение?

Изоляцию пакетов вместе с сетью и переменными окружения Автоматически созданный lock-файл со всеми версиями Отдельный prefix и каталог пакетов для проекта Отдельный процесс Python с собственным ядром системы

Вопрос 3 из 20

Почему команда `python -m pip install package` надёжнее простого `pip install package`?

Она проверяет зависимости, но не меняет окружение Она устанавливает пакет без обращения к индексу Запускается `pip` именно выбранного интерпретатора Она сама выбирает последнюю версию, совместимую со всем проектом

Вопрос 4 из 20

Две библиотеки требуют несовместимые версии общей зависимости. Что произошло?

Файл требований разобран, но в нём не хватает кодировки Конфликт ограничений в графе зависимостей Каталог виртуального окружения создан другой версией ОС Установщик не поддерживает зависимости второго уровня

Вопрос 5 из 20

Что означает ограничение `lib>=2,<3`?

Разрешены ветки 2.x и 3.x, кроме самих 2.0 и 3.0 Разрешены версии не ниже 2 и строго ниже 3 Разрешён диапазон от 2.0 до 3.0 включительно Разрешены версии строго выше 2 и не выше 3

Вопрос 6 из 20

Как понять, активировано ли ожидаемое окружение?

Сверить только значение переменной окружения `VIRTUAL_ENV` Проверить, что пути указывают внутрь нужного каталога окружения Проверить, что команда Python получила другое отображаемое имя Убедиться, что в `sys.path` больше одного элемента

Вопрос 7 из 20

Что стоит фиксировать для воспроизводимого развёртывания приложения?

Точные версии всего дерева либо проверенный lock-файл Версию редактора и расширений на машине сборки Список всех строк `import`, найденных в исходном коде Только названия прямых библиотек без ограничений версий

Вопрос 8 из 20

Почему нельзя считать `pip freeze` идеальным описанием намерений проекта?

Он смешивает прямые, транзитивные и случайно установленные пакеты Он сохраняет диапазоны версий проекта вместо установленных версий Он исключает пакеты, поставленные отдельными командами Он показывает только зависимости, перечисленные разработчиком вручную

Вопрос 9 из 20

Как безопаснее проверить обновление крупной зависимости?

Проверить обновление в чистом окружении тестами и заметками Удалить прежний файл зависимостей и разрешить граф заново без сравнения Сначала заменить версию на рабочем сервере и наблюдать за ошибками Принять предупреждения установщика как несущественные, если импорт проходит

Вопрос 10 из 20

Что покажет `pip check`?

Отсутствующие или несовместимые зависимости установленных пакетов Известные уязвимости пакетов по внешней базе данных Расхождения между lock-файлом и удалённым индексом Ошибки импорта в исходных файлах текущего проекта

Вопрос 11 из 20

Зачем разделять рабочие и развивающие зависимости?

Чтобы не ставить в рабочую среду тестовые инструменты Чтобы тестовый фреймворк не видел импортируемое приложение Чтобы для разработки и выпуска использовались разные интерпретаторы языка Чтобы рабочие библиотеки можно было устанавливать без версий

Вопрос 12 из 20

Что означает editable-установка собственного пакета?

Пакет становится доступен для изменения любому пользователю машины Код берётся из рабочей директории, поэтому изменения видны без переустановки При установке перестают проверяться требования зависимостей Исходники копируются в каждый модуль, который импортирует пакет

Вопрос 13 из 20

Почему активация venv не обязательна технически?

Окружение подключается к каждому процессу Python при создании каталога Пакеты окружения одновременно устанавливаются и в глобальный Python Сценарий активации нужен лишь для создания и удаления окружения Можно напрямую вызвать `.venv/bin/python` или соответствующий путь в Windows

Вопрос 14 из 20

Каталог `.venv` уже существует и содержит старые пакеты. Как команда `python -m venv --clear .venv` изменит его?

Обновляет установленные пакеты до последних версий Удаляет глобальный кэш `pip`, сохраняя окружение Удаляет весь проект вместе с каталогом `.venv` Очищает каталог `.venv` и создаёт окружение заново

Вопрос 15 из 20

Ограничение `critical-lib>=1` допускает несовместимую будущую основную версию. Какое исправление сузит допустимый диапазон?

Заставляет `pip` игнорировать транзитивные зависимости Разрешает только самую первую версию 1.0 Задать диапазон `critical-lib>=1,<2` Запрещает устанавливать исправления в ветке 1.x

Вопрос 16 из 20

Для чего нужны хеши пакетов в строгом файле зависимостей?

Чтобы проверить лицензию пакета без доступа к сети Чтобы подтвердить точное содержимое скачанного артефакта Чтобы скрыть имя и версию пакета в файле Чтобы ускорить импорт пакета после установки

Вопрос 17 из 20

Почему не стоит хранить каталог `.venv` в репозитории?

Git хранит только текстовые файлы и не сможет добавить библиотеки Окружение велико, зависит от платформы и воспроизводится по описанию Без каталога `.venv` инструменты не смогут прочитать исходный код Скопированное окружение невозможно запустить даже на той же машине

Вопрос 18 из 20

Как получить версию дистрибутива `pip`, установленного именно в текущем интерпретаторе Python?

Взять `sys.version`, потому что это версия установленного `pip` Прочитать вывод системной команды `pip` без привязки к интерпретатору Вызвать `importlib.metadata.version("pip")` Прочитать требуемую версию из метаданных проекта, не проверяя установку

Вопрос 19 из 20

Установка проходит у автора, но падает на чистой машине. Какие различия среды нужно проверить в этом граничном сценарии?

Установить несколько глобальных версий спорных библиотек Отключить проверку сертификатов, чтобы исключить влияние индекса Перенести каталог `site-packages` автора на новую машину целиком Сверить Python, платформу, lock-файл и журнал установки

Вопрос 20 из 20

Нужно спроектировать повторяемый выпуск библиотеки для установки в нескольких поддерживаемых средах. Какой набор артефактов выбрать?

Версионированные wheel-файлы для нужных платформ и ABI; для чистого Python — один универсальный wheel Каталог `__pycache__`, собранный на машине разработчика Архив активного виртуального окружения со всеми временными файлами Исходная папка без версии, метаданных и записи о сборке

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу