Pipenv:新しいPythonパッケージングツールのガイド

Pipenv:新しいPythonパッケージングツールのガイド

Pipenvは、 + pip ++ virtualenv +、および古き良き `+ requirements.txt +`を使用した一般的なワークフローに関連するいくつかの一般的な問題を解決するPython用のパッケージツールです。

いくつかの一般的な問題に対処することに加えて、開発プロセスを単一のコマンドラインツールに統合および簡素化します。

このガイドでは、Pipenvが解決する問題、およびPipenvでPythonの依存関係を管理する方法について説明します。 さらに、Pipenvがhttps://realpython.com/python-modules-packages/[package]ディストリビューションの以前のメソッドにどのように適合するかについても説明します。

*無料ボーナス:*リンク:[ここをクリックして5日間の無料クラスにアクセスしてください]。Pip、PyPI、Virtualenv、要件ファイルなどのツールで一般的な依存関係管理の問題を回避する方法を示します。

Pipenvが解決する問題

Pipenvの利点を理解するには、Pythonでのパッケージ化と依存関係管理の現在の方法を理解することが重要です。

サードパーティのパッケージを処理する一般的な状況から始めましょう。 次に、完全なPythonアプリケーションをデプロイする方法を構築します。

`+ requirements.txt +`による依存関係管理

`+ flask +`のようなサードパーティパッケージを使用するPythonプロジェクトで作業していると想像してください。 他の開発者や自動システムがアプリケーションを実行できるように、その要件を指定する必要があります。

そこで、 `+ requirements.txt `ファイルに ` flask +`依存関係を含めることにします。

flask

すばらしいことは、すべてがローカルで正常に機能することです。しばらくの間アプリをハッキングしてから、本番に移行することにしました。 ここが少し怖いところです…

上記の `+ requirements.txt `ファイルは、使用する ` flask `のバージョンを指定していません。 この場合、 ` pip install -r requirements.txt +`はデフォルトで最新バージョンをインストールします。 これは、アプリケーションを壊す最新バージョンのインターフェイスまたは動作の変更がない限り問題ありません。

この例のために、 `+ flask +`の新しいバージョンがリリースされたとしましょう。 ただし、開発中に使用したバージョンとの後方互換性はありません。

ここで、アプリケーションを実稼働環境にデプロイし、「+ pip install -r requirements.txt 」を実行するとします。 Pipは、後方互換性のない最新バージョンの ` flask +`を取得します。そのように、実稼働環境でアプリケーションが破損します。

「しかし、それは私のマシンで機能しました!」—私は自分自身がそこにいましたが、それは素晴らしい気分ではありません。

この時点で、開発中に使用した `+ flask `のバージョンが正常に機能したことがわかります。 そこで、物事を修正するために、 ` requirements.txt `でもう少し具体的になるようにしようとします。 _version specifier_を ` flask +`依存関係に追加します。 これは_pinning_依存関係とも呼ばれます:

flask==0.12.1

`+ flask `依存関係を特定のバージョンに固定すると、 ` pip install -r requirements.txt `により、開発中に使用した正確なバージョンの ` flask +`が設定されます。 しかし、本当にそうですか?

`+ flask `自体にも依存関係があることに注意してください( ` pip `は自動的にインストールされます)。 ただし、 ` flask `自体は、依存関係の正確なバージョンを指定していません。 たとえば、任意のバージョンの「 Werkzeug> = 0.14 +」を許可します。

繰り返しになりますが、この例のために、新しいバージョンの「+ Werkzeug +」がリリースされたとしましょう。ただし、アプリケーションに致命的なバグが発生します。

今回、本番環境で `+ pip install -r requirements.txt `を実行すると、その要件が固定されているため、 ` flask == 0.12.1 `が表示されます。 ただし、残念ながら、最新のバグの多いバージョンの「 Werkzeug +」を入手できます。 繰り返しますが、製品は生産中に壊れます。

ここでの本当の問題は、*ビルドが決定論的ではない*ことです。 つまり、同じ入力( `+ requirements.txt +`ファイル)が与えられた場合、pipは常に同じ環境を生成するとは限りません。 現時点では、本番環境の開発マシンにある正確な環境を簡単に複製することはできません。

この問題の典型的な解決策は、「+ pip freeze +」を使用することです。 このコマンドを使用すると、自動的にインストールされるサブ依存関係を含む、現在インストールされているすべてのサードパーティライブラリの正確なバージョンを取得できます。 したがって、開発中のすべてを凍結して、本番環境で同じ環境を確保できます。

`+ pip freeze `を実行すると、 ` requirements.txt +`に追加できる依存関係が固定されます:

click==6.7
Flask==0.12.1
itsdangerous==0.24
Jinja2==2.10
MarkupSafe==1.0
Werkzeug==0.14.1

これらの固定された依存関係により、実稼働環境にインストールされたパッケージが開発環境のパッケージと正確に一致することを保証できるため、製品が予期せず破損することはありません。 残念ながら、この「解決策」はまったく新しい問題につながります。

すべてのサードパーティパッケージの正確なバージョンを指定したので、 `+ flask `のサブ依存関係であっても、これらのバージョンを最新の状態に保つ責任があります。 ` Werkzeug == 0.14.1 `で発見されたセキュリティホールがあり、パッケージメンテナーがすぐに ` Werkzeug == 0.14.2 `でパッチを適用した場合はどうなりますか? パッチを当てていない以前のバージョンの「 Werkzeug 」に起因するセキュリティ上の問題を回避するには、「 Werkzeug == 0.14.2 +」に更新する必要があります。

まず、お使いのバージョンに問題があることに注意する必要があります。 次に、誰かがセキュリティホールを悪用する前に、運用環境で新しいバージョンを取得する必要があります。 そのため、新しいバージョンの「+ Werkzeug == 0.14.2 」を指定するには、手動で「 requirements.txt +」を変更する必要があります。 この状況でわかるように、必要な更新を最新の状態に保つ責任はユーザーにあります。

真実は、コードを壊さない限り、どのバージョンの `+ Werkzeug +`がインストールされるかは本当に気にしないということです。 実際に、バグ修正、セキュリティパッチ、新機能、最適化などを確実に取得するために、おそらく最新バージョンが必要になります。

本当の質問は次のとおりです。「サブ依存関係のバージョンを更新する責任を負うことなく、Pythonプロジェクトの決定論的ビルドをどのように許可しますか?」*

_ ネタバレ注意:簡単な答えはPipenvを使用することです。 _

異なる依存関係を持つプロジェクトの開発

ギアを少し変えて、複数のプロジェクトで作業しているときに発生する別の一般的な問題について話しましょう。 「+ ProjectA 」には「 django == 1.9 」が必要ですが、「 ProjectB 」には「 django == 1.10 +」が必要だと想像してください。

デフォルトでは、Pythonはすべてのサードパーティパッケージをシステム全体の場所に保存しようとします。 これは、「+ ProjectA 」と「 ProjectB 」を切り替えるたびに、正しいバージョンの「 django +」がインストールされていることを確認する必要があることを意味します。 これにより、各プロジェクトの要件を満たすためにパッケージをアンインストールおよび再インストールする必要があるため、プロジェクト間の切り替えが困難になります。

標準的な解決策は、独自のPython実行可能ファイルとサードパーティのパッケージストレージがあるhttps://realpython.com/python-virtual-environments-a-primer/[仮想環境]を使用することです。 これにより、「+ ProjectA 」と「 ProjectB 」が適切に分離されます。 同じパッケージ保管場所を共有していないため、プロジェクトを簡単に切り替えることができます。 ` PackageA `は、独自の環境で必要な ` django `のバージョンを保持でき、 ` PackageB `は必要なものを完全に分離できます。 このための非常に一般的なツールは、 ` virtualenv `(またはPython 3の ` venv +`)です。

Pipenvには仮想環境管理が組み込まれているため、パッケージ管理用の単一のツールを使用できます。

依存関係の解決

依存関係の解決とはどういう意味ですか? 次のような `+ requirements.txt +`ファイルがあるとします:

package_a
package_b

「+ package_a 」にはサブ依存関係「 package_c 」があり、「 package_a 」にはこのパッケージの特定のバージョン「 package_c> = 1.0 」が必要だとします。 同様に、 ` package_b `のサブ依存性は同じですが、 ` package_c ⇐ 2.0 +`が必要です。

理想的には、 + package_a +`と `+ package_b +`をインストールしようとすると、インストールツールは `+ package_c +( `> = 1.0 +`と ` ⇐ 2.0 +`である)の要件を確認して選択します。これらの要件を満たすバージョン。 プログラムが最終的に機能するように、ツールが依存関係を解決することを願っています。 これが、「依存関係の解決」という意味です。

残念ながら、現時点ではpip自体には実際の依存関係の解決はありませんが、それをサポートするhttps://github.com/pypa/pip/issues/988 [未解決の問題]があります。

pipが上記のシナリオを処理する方法は次のとおりです。

  1. + package_a +`をインストールし、最初の要件( `+ package_c> = 1.0 +)を満たす `+ package_c +`のバージョンを探します。

  2. 次に、Pipは最新のバージョンの `+ package_c `をインストールして、その要件を満たします。 ` package_c +`の最新バージョンが3.1だとしましょう。

これがトラブルの(潜在的な)始まりです。

pipによって選択された `+ package_c `のバージョンが将来の要件に適合しない場合( ` package_c ⇐ 2.0 `が必要な ` package_b +`など)、インストールは失敗します。

この問題の「解決策」は、 + requirements.txt +`ファイルでサブ依存関係に必要な範囲( `+ package_c +)を指定することです。 そのようにして、pipはこの競合を解決し、それらの要件を満たすパッケージをインストールできます。

package_c>=1.0,<=2.0
package_a
package_b

前と同じように、サブ依存関係( + package_c +)に直接関わっています。 これの問題は、 + package_a +`が知らずに要件を変更した場合、指定した要件( `+ package_c> = 1.0、⇐ 2.0 +)が受け入れられなくなり、インストールが失敗する可能性があることです。 本当の問題は、サブ依存関係の要件を最新の状態に保つ責任があることです。

理想的には、インストールツールは、サブ依存バージョンを明示的に指定しなくても、すべての要件を満たすパッケージをインストールするのに十分なほどスマートです。

Pipenvの概要

問題に対処したので、Pipenvがどのようにそれらを解決するかを見てみましょう。

まず、インストールしましょう:

$ pip install pipenv

Pipenvは基本的には置換として機能するため、これを行うと、「+ pip 」を事実上忘れることができます。 また、2つの新しいファイル、https://github.com/pypa/pipfile [` Pipfile `](これは ` requirements.txt `を置き換えることを意図しています)と ` Pipfile.lock +`(決定性を有効にする)ビルド)。

Pipenvは、ボンネットの下で `+ pip `と ` virtualenv +`を使用しますが、単一のコマンドラインインターフェイスでそれらの使用を簡素化します。

使用例

素晴らしいPythonアプリケーションの作成から始めましょう。 まず、仮想環境でシェルを生成して、このアプリの開発を分離します。

$ pipenv shell

これにより、仮想環境がまだ存在しない場合に作成されます。 Pipenvは、すべての仮想環境をデフォルトの場所に作成します。 Pipenvのデフォルトの動作を変更する場合は、https://docs.pipenv.org/advanced/#configuration-with-environment-variables [設定の環境変数]がいくつかあります。

それぞれ引数 `-two +`および `-three `を使用して、Python 2または3環境の作成を強制できます。 それ以外の場合、Pipenvはデフォルトの ` virtualenv +`が検出したものを使用します。

_ サイドノート:より具体的なバージョンのPythonが必要な場合は、必要なバージョンで +-python +`引数を指定できます。 例: `+-python 3.6 + _

これで、必要なサードパーティのパッケージ、 `+ flask `をインストールできます。 ああ、でも最新バージョンではなくバージョン ` 0.12.1 +`が必要なことはわかっているので、具体的に説明してください。

$ pipenv install flask==0.12.1

端末に次のようなものが表示されるはずです。

Adding flask==0.12.1 to Pipfile's [packages]...
Pipfile.lock not found, creating...

`+ Pipfile `と ` Pipfile.lock `の2つのファイルが作成されます。 これらについてはすぐに詳しく見ていきます。 いくつかの数値計算のために、別のサードパーティパッケージ「 numpy +」をインストールしましょう。 特定のバージョンは必要ないので、指定しないでください。

$ pipenv install numpy

バージョン管理システム(VCS)から何かを直接インストールしたい場合は、できます! `+ pip `で指定するのと同じように場所を指定します。 たとえば、バージョン管理から ` requests +`ライブラリをインストールするには、次の手順を実行します。

$ pipenv install -e git+https://github.com/requests/requests.git#egg=requests

上記の「+ -e +」引数に注意して、インストールを編集可能にします。 現在、Pipenvがサブ依存関係の解決を行うには、https://pipenv.readthedocs.io/en/latest/basics/#a-note-about-vcs-dependencies [これが必要です]。

この素晴らしいアプリケーション用のユニットテストもいくつかあり、それらを実行するために `+ pytest `を使用するとします。 本番環境では ` pytest `は必要ないので、この依存関係が `-dev +`引数を使用した開発専用であることを指定できます。

$ pipenv install pytest --dev

`-dev +`引数を指定すると、依存関係が ` Pipfile `の特別な ` [dev-packages] `の場所に配置されます。 これらの開発パッケージは、 ` pipenv install `で `-dev +`引数を指定した場合にのみインストールされます。

異なるセクションでは、開発にのみ必要な依存関係と、ベースコードが実際に機能するために必要な依存関係を分けています。 通常、これは、「+ dev-requirements.txt 」や「 test-requirements.txt 」などの追加の要件ファイルで実現されます。 現在、すべてが異なるセクションの下の単一の ` Pipfile +`に統合されています。

さて、ローカル開発環境ですべてが動作し、本番環境にプッシュする準備ができたとしましょう。 そのためには、本番環境で同じ環境を使用できるように環境をロックする必要があります。

$ pipenv lock

これにより、 `+ Pipfile.lock +`が作成/更新されます。これは、手動で編集する必要はありません(また、意図することもありません)。 常に生成されたファイルを使用する必要があります。

ここで、本番環境でコードと `+ Pipfile.lock +`を取得したら、記録された最後の成功した環境をインストールする必要があります。

$ pipenv install --ignore-pipfile

これは、インストールのために `+ Pipfile `を無視し、 ` Pipfile.lock `にあるものを使用するようPipenvに指示します。 この ` Pipfile.lock `が与えられると、Pipenvは、 ` pipenv lock +`を実行したときとまったく同じ環境を作成します。

ロックファイルは、環境内のパッケージのすべてのバージョンのスナップショットを取得することにより、確定的なビルドを可能にします( `+ pip freeze +`の結果に似ています)。

ここで、別の開発者がコードにいくつかの追加を行いたいとします。 この状況では、 `+ Pipfile +`を含むコードを取得し、次のコマンドを使用します。

$ pipenv install --dev

これにより、開発に必要なすべての依存関係がインストールされます。これには、通常の依存関係と、「+ install 」時に「-dev +」引数で指定した依存関係の両方が含まれます。

_ Pipfileで正確なバージョンが指定されていない場合、 `+ install +`コマンドは、依存関係(およびサブ依存関係)がバージョンを更新する機会を与えます。 _

これは、前述の問題の一部を解決するため、重要な注意事項です。 例として、依存関係の1つの新しいバージョンが利用可能になったとします。 この依存関係の特定のバージョンは必要ないため、 `+ Pipfile `で正確なバージョンを指定しないでください。 ` pipenv install +`を実行すると、新しいバージョンの依存関係が開発環境にインストールされます。

ここで、コードを変更し、いくつかのテストを実行して、すべてが期待どおりに機能していることを確認します。 (ユニットテストはありますか?)これまでと同様に、環境を `+ pipenv lock `でロックすると、依存関係の新しいバージョンで更新された ` Pipfile.lock +`が生成されます。 前と同じように、ロックファイルを使用して、この新しい環境を運用環境で複製できます。

このシナリオからわかるように、開発環境と運用環境が同じであることを保証するために本当に必要としない正確なバージョンを強制する必要はなくなりました。 また、「気にしない」サブ依存関係の更新を常に把握する必要はありません。 Pipenvを使用したこのワークフローは、優れたテストと組み合わされ、すべての依存関係管理を手動で行う問題を修正します。

Pipenvの依存関係解決アプローチ

Pipenvは、コア依存関係のすべての要件を満たすサブ依存関係のインストールを試みます。 ただし、競合する依存関係がある場合( `+ package_a `には ` package_c> = 1.0 `が必要ですが、 ` package_b `には ` package_c <1.0 +`が必要です)、Pipenvはロックファイルを作成してwilを出力できません次のようなエラー:

Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  You can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
Could not find a version that matches package_c>=1.0,package_c<1.0

警告にあるように、トップレベルの依存関係とそのサブ依存関係を理解するために、依存関係グラフを表示することもできます。

$ pipenv graph

このコマンドは、依存関係を示すツリーのような構造を出力します。 例を示しましょう。

Flask==0.12.1
  - click [required: >=2.0, installed: 6.7]
  - itsdangerous [required: >=0.21, installed: 0.24]
  - Jinja2 [required: >=2.4, installed: 2.10]
    - MarkupSafe [required: >=0.23, installed: 1.0]
  - Werkzeug [required: >=0.7, installed: 0.14.1]
numpy==1.14.1
pytest==3.4.1
  - attrs [required: >=17.2.0, installed: 17.4.0]
  - funcsigs [required: Any, installed: 1.0.2]
  - pluggy [required: <0.7,>=0.5, installed: 0.6.0]
  - py [required: >=1.5.0, installed: 1.5.2]
  - setuptools [required: Any, installed: 38.5.1]
  - six [required: >=1.10.0, installed: 1.11.0]
requests==2.18.4
  - certifi [required: >=2017.4.17, installed: 2018.1.18]
  - chardet [required: >=3.0.2,<3.1.0, installed: 3.0.4]
  - idna [required: >=2.5,<2.7, installed: 2.6]
  - urllib3 [required: <1.23,>=1.21.1, installed: 1.22]

+ pipenv graph +`の出力から、以前にインストールしたトップレベルの依存関係( `+ Flask ++ numpy ++ pytest +、および + requests +)を確認できます。依存するパッケージ。

さらに、ツリーを逆にして、それを必要とする親のサブ依存関係を表示できます。

$ pipenv graph --reverse

この逆ツリーは、競合するサブ依存関係を把握しようとする場合により便利です。

Pipfile

Pipfileは、 + requirements.txt +`を置き換える予定です。 Pipenvは現在、 `+ Pipfile +`を使用するためのリファレンス実装です。 https://github.com/pypa/pipfile#pip-integration-eventual [+ pip +`自体がこれらのファイルを処理できるようになる]と思われます。 また、https://packaging.python.org/tutorials/managing-dependencies/#managing-dependencies [PipenvはPython自体が推奨する公式のパッケージ管理ツールです。

+ Pipfile +`の構文はhttps://github.com/toml-lang/toml[TOML]であり、ファイルはセクションに分割されています。 開発専用パッケージの場合は `+ [dev-packages] +、最低限必要なパッケージの場合は + [packages] +、特定のバージョンのPythonなどの他の要件の場合は `+ [requires] +`です。 以下のサンプルファイルを参照してください。

[[source]]
url = "https://pypi.python.org/simple"
verify_ssl = true
name = "pypi"

[dev-packages]
pytest = "*"

[packages]
flask = "==0.12.1"
numpy = "*"
requests = {git = "https://github.com/requests/requests.git", editable = true}

[requires]
python_version = "3.6"

理想的には、 `+ Pipfile `にサブ依存関係がないようにする必要があります。 つまり、実際にインポートして使用するパッケージのみを含める必要があります。 ` chardset `を ` Pipfile `に保持する必要はありません。単にそれが ` requests `のサブ依存関係だからです。 (Pipenvは自動的にインストールします。) ` Pipfile +`は、パッケージに必要な最上位の依存関係を伝えます。

Pipfile.lock

このファイルは、環境を再現するための正確な要件を指定することにより、確定的なビルドを可能にします。 より安全な検証をサポートするためのパッケージとハッシュの正確なバージョンが含まれており、https://pip.pypa.io/en/stable/reference/pip_install/#hash-checking-mode [`+ pip `自体がサポートするようになりました] 。 サンプルファイルは次のようになります。 このファイルの構文はJSONであり、ファイルの一部を「 …​ +」で除外したことに注意してください。

{
    "_meta": {
        ...
    },
    "default": {
        "flask": {
            "hashes": [
                "sha256:6c3130c8927109a08225993e4e503de4ac4f2678678ae211b33b519c622a7242",
                "sha256:9dce4b6bfbb5b062181d3f7da8f727ff70c1156cbb4024351eafd426deb5fb88"
            ],
            "version": "==0.12.1"
        },
        "requests": {
            "editable": true,
            "git": "https://github.com/requests/requests.git",
            "ref": "4ea09e49f7d518d365e7c6f7ff6ed9ca70d6ec2e"
        },
        "werkzeug": {
            "hashes": [
                "sha256:d5da73735293558eb1651ee2fddc4d0dedcfa06538b8813a2e20011583c9e49b",
                "sha256:c3fd7a7d41976d9f44db327260e263132466836cef6f91512889ed60ad26557c"
            ],
            "version": "==0.14.1"
        }
        ...
    },
    "develop": {
        "pytest": {
            "hashes": [
                "sha256:8970e25181e15ab14ae895599a0a0e0ade7d1f1c4c8ca1072ce16f25526a184d",
                "sha256:9ddcb879c8cc859d2540204b5399011f842e5e8823674bf429f70ada281b3cc6"
            ],
            "version": "==3.4.1"
        },
        ...
    }
}

すべての依存関係に指定された正確なバージョンに注意してください。 `+ Pipfile `にない ` werkzeug `のようなサブ依存関係も、この ` Pipfile.lock +`に表示されます。 ハッシュは、開発時と同じパッケージを取得するために使用されます。

このファイルを手動で変更しないでください。 `+ pipenv lock +`で生成されることを意図しています。

Pipenvの追加機能

次のコマンドを使用して、デフォルトのエディターでサードパーティのパッケージを開きます。

$ pipenv open flask

これにより、デフォルトのエディターで `+ flask `パッケージが開きます。または、 ` EDITOR `環境変数でプログラムを指定できます。 たとえば、https://www.sublimetext.com/[Sublime Text]を使用しているので、 ` EDITOR = subl +`を設定するだけです。 これにより、使用しているパッケージの内部を掘り下げることが非常に簡単になります。

シェルを起動せずに、仮想環境でコマンドを実行できます。

$ pipenv run <insert command here>

ご使用の環境のセキュリティ脆弱性(およびhttps://www.python.org/dev/peps/pep-0508/[PEP 508]要件)を確認します。

$ pipenv check

次に、パッケージが不要になったとします。 アンインストールできます:

$ pipenv uninstall numpy

さらに、仮想環境からインストール済みのすべてのパッケージを完全に消去するとします。

$ pipenv uninstall --all

devパッケージを削除するには、「-all +」を「-all-dev +」に置き換えることができます。

Pipenvは、最上位ディレクトリに `+ .env `ファイルが存在する場合、環境変数の自動読み込みをサポートします。 そうすれば、 ` pipenv shell `で仮想環境を開くと、ファイルから環境変数がロードされます。 ` .env +`ファイルには、キーと値のペアのみが含まれています。

SOME_ENV_CONFIG=some_value
SOME_OTHER_ENV_CONFIG=some_other_value

最後に、ここにあるものを見つけるための簡単なコマンドがあります。 仮想環境の場所を確認する方法:

$ pipenv --venv

プロジェクトのホームの場所を確認する方法:

$ pipenv --where

パッケージ配布

コードをパッケージとして配布する場合は、このすべてがどのように機能するかを尋ねるかもしれません。

はい、コードをパッケージとして配布する必要があります

Pipenvは `+ setup.py +`ファイルをどのように使用しますか?

その質問には多くのニュアンスがあります。 まず、ビルド/配布システムとして「+ setuptools 」を使用している場合は、「 setup.py 」ファイルが必要です。 これはしばらくの間事実上の標準でしたが、https://www.python.org/dev/peps/pep-0518/[最近の変更]により、 ` setuptools +`の使用がオプションになりました。

つまり、https://github.com/takluyver/flit [flit]のようなプロジェクトは、新しい `+ pyproject.toml `を使用して、 ` setup.py +`を必要としない別のビルドシステムを指定できます。

そうは言っても、近い将来、「+ setuptools 」とそれに付随する「 setup.py +」が多くの人にとってデフォルトの選択肢になります。

パッケージを配布する方法として「+ setup.py +」を使用する場合の推奨ワークフローは次のとおりです。

  • + setup.py +

  • `+ install_requires +`キーワードには、https://packaging.python.org/discussions/install-requires-vs-requirements/[「正しく実行する必要が最小限です。」]

  • + Pipfile +

  • パッケージの具体的な要件を表します

  • Pipenvを使用してパッケージをインストールすることにより、最低限必要な依存関係を `+ setup.py +`から取得します。

  • `+ pipenv install '-e。' +`を使用します

  • これにより、 `+ Pipfile `に `" e1839a8 "= {path ="。 "、editable = true} +`のような行が表示されます。

  • + Pipfile.lock +

  • `+ pipenv lock +`から生成された再現可能な環境の詳細

明確にするために、最小要件を直接「+ pipenv install 」ではなく「 setup.py 」に入れます。 次に、 ` pipenv install '-e。' `コマンドを使用して、パッケージを編集可能としてインストールします。 これにより、すべての要件が「 setup.py 」から環境に取り込まれます。 次に、 ` pipenv lock +`を使用して、再現可能な環境を取得できます。

コードをパッケージとして配布する必要はありません

すばらしいです! 配布またはインストールすることを意図していないアプリケーション(個人用Webサイト、デスクトップアプリケーション、ゲームなど)を開発している場合、 `+ setup.py +`は必要ありません。

この状況では、 + Pipfile +/`+ Pipfile.lock +`コンボを使用して、前述のフローで依存関係を管理し、本番環境で再現可能な環境をデプロイできます。

私はすでに `+ requirements.txt `を持っています。 ` Pipfile +`に変換するにはどうすればよいですか?

`+ pipenv install `を実行すると、 ` requirements.txt `が自動的に検出され、それが ` Pipfile +`に変換され、次のように出力されます。

requirements.txt found, instead of Pipfile! Converting…
Warning: Your Pipfile now contains pinned versions, if your requirements.txt did.
We recommend updating your Pipfile to specify the "*" version, instead.

_ 上記の警告に注意してください。 _

`+ requirements.txt `ファイルに正確なバージョンを固定している場合は、本当に必要な正確なバージョンのみを指定するように ` Pipfile `を変更する必要があります。 これにより、移行の本当のメリットを得ることができます。 たとえば、次のものがあるが、実際にはその正確なバージョンの ` numpy +`を必要としないとしましょう:

[packages]
numpy = "==1.14.1"

依存関係に特定のバージョン要件がない場合は、ワイルドカード文字「+ * +」を使用して、すべてのバージョンをインストールできることをPipenvに通知できます。

[packages]
numpy = "*"

「+ * +」が付いたバージョンを許可することに不安がある場合は、通常、既に使用しているバージョン以上を指定して、新しいバージョンを引き続き利用できるようにするのが安全です。

[packages]
numpy = ">=1.14.1"

もちろん、新しいリリースを常に最新の状態に保つには、パッケージが変更されたときにコードが期待どおりに機能することを保証する責任があります。 これは、コードの機能リリースを保証する場合、このPipenvフロー全体にテストスイートが不可欠であることを意味します。

パッケージの更新、テストの実行、すべてのパスの確認、環境のロックを許可すると、重大な変更が導入されていないことを簡単に知ることができます。 依存関係が原因で問題が発生した場合は、いくつかの回帰テストを記述し、依存関係のバージョンにさらに制限を加える可能性があります。

たとえば、 `+ pipenv install `を実行した後に ` numpy == 1.15 +`がインストールされ、コードが破損した場合、開発中またはテスト中に気付くと思いますが、いくつかのオプションがあります。

  1. 依存関係の新しいバージョンで機能するようにコードを更新します。 依存関係の以前のバージョンとの後方互換性が不可能な場合、必要なバージョンを ` Pipfile `に追加する必要もあります:

[packages]
numpy = ">=1.15"
  1. `+ Pipfile `の依存関係のバージョンを、コードを破壊したばかりのバージョンの ` <+`に制限します。

[packages]
numpy = ">=1.14.1,<1.15"

オプション1は、コードが最新の依存関係を使用していることを保証するため、推奨されます。 ただし、オプション2の方が時間がかからず、コードの変更は不要で、依存関係の制限のみが必要です。

同じ `+ -r +`引数を使用して要件ファイルからインストールすることもできます。

$ pipenv install -r requirements.txt

`+ dev-requirements.txt `または類似のものがある場合は、それらを ` Pipfile `に追加することもできます。 `-dev +`引数を追加するだけで、適切なセクションに配置されます。

$ pipenv install -r dev-requirements.txt --dev

さらに、他の方法で、 `+ Pipfile +`から要件ファイルを生成できます:

$ pipenv lock -r > requirements.txt
$ pipenv lock -r -d > dev-requirements.txt

次は何ですか?

Pythonエコシステムの自然な進歩は、パッケージインデックス(PyPIなど)からパッケージを取得およびビルドする際に、最低限必要な依存関係をインストールするために `+ Pipfile +`を使用するビルドシステムになると思われます。 Pipfile design specificationはまだ開発中であり、Pipenvは単なるリファレンス実装であることに注意してください。

そうは言っても、「+ setup.py 」の「 install_requires 」セクションが存在せず、代わりに「 Pipfile 」が最小要件として参照される未来を見ることができました。 または、 ` setup.py `が完全に削除され、メタデータやその他の情報を別の方法で取得し、必要な依存関係を取得するために ` Pipfile +`を使用します。

Pipenvはチェックアウトする価値がありますか?

絶対に。 既に使用しているツール( + pip ++ virtualenv +)を単一のインターフェースに統合する方法としても。 ただし、それだけではありません。 `+ Pipfile +`を追加すると、本当に必要な依存関係のみを指定できます。

開発環境を複製できるようにするためだけに、すべてのバージョンを自分で管理するという頭痛の種がなくなりました。 `+ Pipfile.lock +`を使用すると、環境をどこでも正確に再現できることを知って安心して開発できます。

それに加えて、 `+ Pipfile `形式は ` pip +`のような公式のPythonツールで採用およびサポートされる可能性が非常に高いため、ゲームの先を行くことは有益です。 ああ、あなたもすべてのコードをPython 3に更新していることを確認してください:https://www.python.org/dev/peps/pep-0373/#maintenance-releases[2020はすぐに登場します]。

参照、さらに読む、興味深い議論など

*無料ボーナス:*リンク:[ここをクリックして5日間の無料クラスにアクセスしてください]。Pip、PyPI、Virtualenv、要件ファイルなどのツールで一般的な依存関係管理の問題を回避する方法を示します。