Эквивалент `package.json 'и` package-lock.json` для `pip`

Question

Менеджеры пакетов для JavaScript, например npm и yarn, используют package.json для указания зависимостей верхнего уровня и создают файл блокировки для отслеживания конкретных версий всех пакетов (т.е. зависимостей верхнего уровня и подуровня), которые установлены в результате.

Кроме того, package.json позволяет нам сделатьРазличие между типами зависимостей верхнего уровня, таких как production и development .

Для Python, с другой стороны, у нас есть pip.Я предполагаю, что pip эквивалент lock -файла будет результатом pip freeze > requirements.txt.

Однако, если вы поддерживаете только этот единственный файл requirements.txt, трудно различить зависимости верхнего уровня и подуровня (вам понадобится, например, pipdeptree -r, чтобы выяснить это).Это может быть очень неприятно, если вы хотите удалить или изменить зависимости верхнего уровня, так как легко оставить потерянные пакеты (насколько я знаю, pip не удаляет суб-зависимости когда вы pip uninstall пакет).

Теперь мне интересно : существует ли какое-то соглашение для работы с различными типами этих requirements файлов и разграничения между верхним уровнем и вложеннымзависимости уровня с pip?

Например, я могу представить себе requirements-prod.txt, который содержит только требования верхнего уровня для производственной среды, в качестве (упрощенного) эквивалента package.json, иrequirements-prod.lock, который содержит выходные данные pip freeze и действует как мой lock -файл.Кроме того, у меня может быть requirements-dev.txt для зависимостей разработки, и так далее, и тому подобное.

Я хотел бы знать, так ли это, или есть ли лучший подход.

ps Тот же вопрос можно задать для conda environment.yml.

Answer 1

На сегодня доступно как минимум два хороших варианта:

1. pipenv использует Pipfile и Pipfile.lock аналогичнокак вы описываете подобные файлы JavaScript.pipenv является «большим» инструментом, чем pip, в том смысле, что он также создает и управляет virtualenvs.

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

2. pip-tools предоставляет команды pip-compile и pip-sync.Здесь requirements.in перечисляет ваши прямые зависимости, часто со свободными ограничениями версий, а pip-compile генерирует заблокированные requirements.txt файлы из ваших .in файлов.

   Лично мне нравится этот инструмент, поскольку он обратно совместим(сгенерированный requirements.txt может быть обработан pip), а инструмент pip-sync гарантирует, что virtualenv точно соответствует заблокированным версиям, удаляя вещи, которых нет в вашем файле «lock».