web-dev-qa-db-ja.com

明示的なバージョンでPipfileおよびPipfile.lockを使用した後でもユーザー間の違い

長すぎて申し訳ありませんが、これはかなり複雑なpipenvの状況です。

私の会社では、pipenv（PipfileとPipfile.lockの両方）を使用して、さまざまなエンジニアのラップトップで使用されるパッケージを制御しています。 AWS LambdaコードのデプロイにもZappaを使用しており、デプロイヤーのラップトップから依存関係を直接パッケージ化してデプロイするため、これはほとんどのチームよりもさらに重要です。したがって、人々のラップトップが依存関係に関して完全に揃っていない場合、誰がそれを展開したかに応じて、クラウドで異なる動作を得ることができます。

PipfileとPipfile.lockで依存関係を完全に制御しようとした後でも、pip freezeとデプロイされたコードのエラーが示すように、異なるラップトップで異なるPythonパッケージを取得することになります。

これが私のラップトップと上司の違いを示している正確なプロセスです（引用したPipfileコードは複数行にありますが、SOのフォーマットに問題があるため、1行に圧縮しています）。

  1. 最初は、[requires] python_version = "3.6" [packages] flask = "*"のようなワイルドカードでパッケージが指定されたPipfileしかありませんでした。また、Pipfile.lockがありませんでした。上司（このプロジェクトの最初のコーダー）は常に--skip-lockを実行していました
  2. より適切に制御するために、Pipfileをアップグレードしてワイルドカードを明示的なバージョンに置き換え、[requires] python_version = "3.6.4" [packages] Flask = "==1.0.2"のようにPythonバージョンをより具体的にすることから始めました。これを行うために、上司のpip freeze出力のコピーを取得し、バージョンをPipfileにコピーしました。ここにリストされているものと名前が一致していました（上流の依存関係であると想定して一致しなかったものはスキップしました。まだそれに触れていませんでした）。私はこれをコミットしました。
  3. まだ問題があったため、Pipfile.lockを使用して上流の依存関係を制御することにしました。ですから、上司はpip installなしで--skip-lockを初めて実行して作成し、それをコミットしました。
  4. Pipfile.lockをプルし、pipenv --rmで環境を削除し、pipenv installで環境を再作成しました
  5. どちらもpip freezeを実行し、出力を比較しましたが、まだいくつかの違いがあります。

上司にpipenv環境を削除して、コミットされたPipfileとPipfile.lockに基づいて再インストールしてもらえると思いますが、それらは彼のpip freezeに基づいているため、何かが変わったとしたら少し驚きます。

だから私はただ疑問に思っています：この動作は本当に予想外ですか？すべてのバージョンがPipfile.lockでロックされている限り、pipenv、Pipfile、および==[version]の組み合わせにより、2人のユーザーが同じパッケージを確実に使用できると常に思っていました。完全に一致させるために他に必要なことはありますか？

それが本当に予期しないものである場合、他に考えられる唯一のことは、彼がpipenv Shellの前にpip freezeを実行しなかった可能性があることですが、Pipfilesに対してうまく並んでいたため、彼はそうしたと思います。

補足：Pipfileの[dev-packages]をバージョンに変換していません。何をするのかわからないので、無関係であると想定しているからです。したがって、それらはまだpylint = "*"のようなものです

追加情報

以下はコメントに応答するための追加情報です...しかし、最初に私が気づいたいくつかの興味深い事柄：

  • 最初のスクリーンショット（pip freezeの差分）の違いは、Pipfileにはありません。
  • pip freezeの出力はPipfile.lockの内容と一致しているようですが、上司の出力は一致していません。これは違いを説明していると思いますが、彼のpip freeze出力が、Pipfile.lockの外部からpipenv lockを実行したことが問題でない限り、彼のpipenv lockによって作成されたpipenv Shellと一致しないことは少し意外です。

コメントに応答するには...これは、私と上司のラップトップの（両方のpipenvシェルからの）pipフリーズ出力間の差分の最初の部分です。

enter image description here

上司のラップトップとPipfile.lockの違いは次のとおりです。 Pipfile.lockは、彼にpipenv lock（pipenv Shellの外ではそれは重要ではないと思います）を実行させ、それを今すぐコミットすることで得られました。次に、それをプルし、pipenv --rmを使用して環境を削除し、pipenv installを実行して、コミットしたばかりのPipfile.lockと次のような違いを得ました。彼のバージョンは再び左側にあります。

これらはすべての違いです。私が得られないことの1つは、pip freezeを使用する場合よりもここで違いが少ない理由です。私たちのPipfileは、まだ2人で同じです。

enter image description here

enter image description here

enter image description here

enter image description here

pythonpipenv
17
Stephen

まったく同じ環境を確実に共有する唯一の方法は、Pipfile.lock（オプションでpipenv sync）を使用して、同じpipenv sync --devと同期することです。

Pipfileは人間のヘルパーであり、Pipfile.lock作成の中間体であり、依存関係が完全に同じであるとは限りません。

内部でのpipenv install呼び出し2 pipenv関数：lockおよびsync。 pipenv lockは、PipfileからPipfile.lockを生成します。 Pipfileの固定されたバージョンでも、固定されたパッケージの依存関係が固定されない可能性があるため（パブリッシャーによって）、異なるタイミングで生成された場合、異なるPipfile.lockが存在する可能性があります。 pipenv sync次に、Pipfile.lockにある正確なパッケージをインストールします。

Pipfile.lockの依存関係から環境を直接インストールするには、pipenv --python 3.6 install --ignore-pipfileを使用する必要があります。そうしないと、Pipfile.lockがPipfileから再生成されます。

問題を簡単に解決するには、Pipfile.lockのバージョンを修正します（バージョン管理を使用すればコミットできますが、もちろんそうします）。次に、どちらもpipenv syncを使用します。

次に、マイナーバージョン、バグ修正を行う限り、Pipfile.lockをまったく同じに保ち、メジャーバージョンの最新の依存関係を取得するために自由に再生成してください。私のプロジェクトでは、Pipfileのほとんどすべての依存関係が固定されていません。新しいメジャーバージョンを開始するときに、Pipfile.lockを更新して新しい依存関係バージョンを試し、すべてをテストし、依存関係を最新のバージョンで下位互換性のない変更が導入された場合は以前のバージョン。次のメジャーバージョンまでPipfile.lockを修正します。

3
gaFF

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.
0
Eric Ihli