Извините за длину, это довольно сложная ситуация с pipenv.
В моей компании мы используем pipenv (вместе с Pipfile
и Pipfile.lock
) для управления пакетами, используемыми на ноутбуках разных инженеров. Для нас это даже важнее, чем для большинства команд, поскольку мы также используем Zappa для развертывания лямбда-кода AWS и, по-видимому, упаковывает зависимости непосредственно с ноутбука-развертывателя для их развертывания. Поэтому, если ноутбуки людей не полностью выровнены с точки зрения зависимостей, мы можем получить различное поведение в облаке в зависимости от того, кто его развернул.
Мы обнаружили, что даже после попытки полностью контролировать зависимости с помощью Pipfile
и Pipfile.lock
, мы получаем разные пакеты Python на наших разных ноутбуках, как показано в pip freeze
и на что указывают ошибки в развернутом коде.
Вот точный процесс, который показывает различия между моим ноутбуком и моим боссом (код Pipfile, который я цитирую, состоит из нескольких строк, но я сокращаю его до одной строки, потому что у меня проблемы с форматированием SO):
- В самом начале все, что у нас было, это
Pipfile
с пакетами, указанными с подстановочными знаками, такими как[requires] python_version = "3.6" [packages] flask = "*"
. Кроме того, у нас не былоPipfile.lock
, мой босс (который был первым программистом в этом проекте) всегда выполнял--skip-lock
- Чтобы лучше управлять, я начал с обновления нашего
Pipfile
чтобы заменить подстановочные знаки явными версиями, а также сделать нашу версию Python более конкретной, например,[requires] python_version = "3.6.4" [packages] Flask = "==1.0.2"
, Чтобы сделать это, я получил копию своего вывода боссаpip freeze
и скопировал версии вPipfile
где было совпадение имен с тем, что было там указано (я пропустил все, что не соответствовало, потому что я полагал, что это была восходящая зависимость и мы еще не касались этого). Я совершил это. - У нас все еще были проблемы, поэтому мы решили начать использовать
Pipfile.lock
для управления зависимостями вверх по течению. Итак, мой босс создал его, впервые запустивpip install
без--skip-lock
, и--skip-lock
это. - Я
Pipfile.lock
, удалил свое окружение с помощьюpipenv --rm
и воссоздал его сpipenv install
- Мы оба запустили
pip freeze
и сравнили результаты, но у нас все еще есть ряд различий.
Я полагаю, что мой босс может удалить свое окружение pipenv
и переустановить его на основе зафиксированных Pipfile
и Pipfile.lock
, но, поскольку они основаны на его pip freeze
я был бы немного удивлен, если это что-то изменило.
Так что мне просто интересно: действительно ли это поведение неожиданно? Я всегда думал, что сочетание pipenv
, Pipfile
и Pipfile.lock
гарантирует, что два человека будут иметь одинаковые пакеты, если каждая версия заблокирована с помощью ==[version]
. Есть ли что-то еще, что нам нужно сделать, чтобы получить очень точное совпадение?
Если это действительно неожиданно, единственное, что я могу подумать, это то, что, возможно, он не запускал pipenv shell
до его pip freeze
, но я думаю, что он сделал это, потому что все хорошо выровнялось с Pipfiles
.
Примечание: я не конвертировал наши [dev-packages]
в Pipfile
чтобы иметь версии, потому что я не уверен, что это делает, и я предполагаю, что это не имеет значения. Так что это все еще как pylint = "*"
ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ
Ниже приведена дополнительная информация для ответа на комментарии... но сначала пару интересных вещей, которые я заметил:
- Ни одно из различий в первом скриншоте (для
pip freeze
diff) не находятся вPipfile
. - Похоже, мой вывод
pip freeze
-Pipfile.lock
содержимомуPipfile.lock
, а мой босс - нет. Я думаю, что это может объяснить различия, но немного удивительно, что его выводpip freeze
не будет соответствоватьPipfile.lock
созданному его собственнойpipenv lock
, если только проблема в том, что онpipenv lock
снаружиpipenv shell
.
Чтобы ответить на комментарии... Вот первая часть различий между выводами замораживания pip (оба из оболочки pipenv) на ноутбуках моего и моего босса:
Вот некоторые Pipfile.lock
в Pipfile.lock
между моими ноутбуками и ноутбуком моего босса. Pipfile.lock
был получен тем, что он запустил pipenv lock
(вне pipenv shell
хотя я полагаю, что это не имеет значения), а затем зафиксировал это прямо сейчас. Затем я вытащил это, удалил мою среду с помощью pipenv --rm
, запустил pipenv install
и получил следующие отличия от Pipfile.lock
который он только что зафиксировал. Его версия снова слева.
Это все различия - я не понимаю, почему у нас здесь меньше различий, чем в случае с pip freeze
. Наш Pipfile
остается неизменным между нами двумя.