различия между пользователями даже после использования Pipfile и Pipfile.lock с явными версиями

Извините за длину, это довольно сложная ситуация с pipenv.

В моей компании мы используем pipenv (вместе с Pipfile и Pipfile.lock) для управления пакетами, используемыми на ноутбуках разных инженеров. Для нас это даже важнее, чем для большинства команд, поскольку мы также используем Zappa для развертывания лямбда-кода AWS и, по-видимому, упаковывает зависимости непосредственно с ноутбука-развертывателя для их развертывания. Поэтому, если ноутбуки людей не полностью выровнены с точки зрения зависимостей, мы можем получить различное поведение в облаке в зависимости от того, кто его развернул.

Мы обнаружили, что даже после попытки полностью контролировать зависимости с помощью Pipfile и Pipfile.lock, мы получаем разные пакеты Python на наших разных ноутбуках, как показано в pip freeze и на что указывают ошибки в развернутом коде.

Вот точный процесс, который показывает различия между моим ноутбуком и моим боссом (код Pipfile, который я цитирую, состоит из нескольких строк, но я сокращаю его до одной строки, потому что у меня проблемы с форматированием SO):

  1. В самом начале все, что у нас было, это Pipfile с пакетами, указанными с подстановочными знаками, такими как [requires] python_version = "3.6" [packages] flask = "*". Кроме того, у нас не было Pipfile.lock, мой босс (который был первым программистом в этом проекте) всегда выполнял --skip-lock
  2. Чтобы лучше управлять, я начал с обновления нашего Pipfile чтобы заменить подстановочные знаки явными версиями, а также сделать нашу версию Python более конкретной, например, [requires] python_version = "3.6.4" [packages] Flask = "==1.0.2", Чтобы сделать это, я получил копию своего вывода босса pip freeze и скопировал версии в Pipfile где было совпадение имен с тем, что было там указано (я пропустил все, что не соответствовало, потому что я полагал, что это была восходящая зависимость и мы еще не касались этого). Я совершил это.
  3. У нас все еще были проблемы, поэтому мы решили начать использовать Pipfile.lock для управления зависимостями вверх по течению. Итак, мой босс создал его, впервые запустив pip install без --skip-lock, и --skip-lock это.
  4. Я Pipfile.lock, удалил свое окружение с помощью pipenv --rm и воссоздал его с pipenv install
  5. Мы оба запустили 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) на ноутбуках моего и моего босса:

enter image description here

Вот некоторые Pipfile.lock в Pipfile.lock между моими ноутбуками и ноутбуком моего босса. Pipfile.lock был получен тем, что он запустил pipenv lock (вне pipenv shell хотя я полагаю, что это не имеет значения), а затем зафиксировал это прямо сейчас. Затем я вытащил это, удалил мою среду с помощью pipenv --rm, запустил pipenv install и получил следующие отличия от Pipfile.lock который он только что зафиксировал. Его версия снова слева.

Это все различия - я не понимаю, почему у нас здесь меньше различий, чем в случае с pip freeze. Наш Pipfile остается неизменным между нами двумя.

enter image description here

enter image description here

enter image description here

enter image description here

Ответы

Ответ 1

pipenv install устанавливает из Pipfile. Восходящие зависимости могут отличаться.

pipenv sync устанавливается из Pipfile.lock. Ничего не будет отличаться.

Это мое понимание от чтения команды помочь.

$ pipenv
Usage: pipenv [OPTIONS] COMMAND [ARGS]...

Commands:
  # ...
  install    Installs provided packages and adds them to Pipfile, or (if no
  # ...
  sync       Installs all packages specified in Pipfile.lock.

Ответ 2

Единственный способ обеспечить совместное использование одной и той же среды - это синхронизировать с тем же Pipfile.lock, с pipenv sync (опционально с pipenv sync pipenv sync --dev).

Pipfile является помощником для людей, промежуточным звеном в создании Pipfile.lock, он не гарантирует, что зависимости точно такие же.

pipenv install вызовы под капотом 2 функции pipenv: lock и sync. pipenv lock сгенерирует Pipfile.lock из вашего Pipfile. Даже с закрепленной версией в Pipfile, возможно иметь разные Pipfile.lock если они генерируются в разные моменты, потому что зависимости закрепленных пакетов могут не закрепляться (в зависимости от издателя). pipenv sync установите точные пакеты, найденные в Pipfile.lock.

Чтобы напрямую установить вашу среду из зависимостей в Pipfile.lock, вы должны использовать pipenv --python 3.6 install --ignore-pipfile, в противном случае Pipfile.lock будет Pipfile.lock из Pipfile.

Чтобы легко решить вашу проблему, исправьте версию Pipfile.lock (вы можете зафиксировать ее, если вы используете контроль версий, но вы, конечно же, делаете это;), тогда оба используют pipenv sync.

Затем сохраняйте Pipfile.lock точно таким же образом, пока вы работаете с минорной версией, исправляете ошибки... и не стесняйтесь обновлять ее, чтобы получить новейшие зависимости для основных версий. В моем проекте почти все зависимости в Pipfile не закреплены, и когда мы запускаем новую основную версию, мы обновляем Pipfile.lock чтобы попробовать новые версии зависимостей, протестировать все, иногда закрепить зависимость в предыдущей версии, если последняя введена в обратном направлении. несовместимые изменения, и мы исправляем Pipfile.lock до следующей основной версии.