ユーザーガイド¶
pip の実行¶
pip はコマンドラインプログラムです。pip をインストールすると、システムに pip
コマンドが追加され、コマンドプロンプトから次のように実行できます。
python -m pip <pip arguments>
python -m pip
は、python として指定した Python インタープリターを使用して pip を実行します。したがって、/usr/bin/python3.7 -m pip
は、/usr/bin/python3.7
にあるインタープリターの pip を実行していることを意味します。
py -m pip <pip arguments>
py -m pip
は、インストールされている最新の Python インタープリターを使用して pip を実行します。詳細については、Python Windows ランチャードキュメントを参照してください。
パッケージのインストール¶
pip は、PyPI、バージョン管理、ローカルプロジェクト、および配布ファイルから直接インストールをサポートしています。
最も一般的なシナリオは、要件指定子を使用してPyPIからインストールすることです。
python -m pip install SomePackage # latest version
python -m pip install SomePackage==1.0.4 # specific version
python -m pip install 'SomePackage>=1.0.4' # minimum version
py -m pip install SomePackage # latest version
py -m pip install SomePackage==1.0.4 # specific version
py -m pip install 'SomePackage>=1.0.4' # minimum version
詳細および例については、pip install リファレンスを参照してください。
基本認証資格情報
これは現在、認証で説明されています。
netrc サポート
これは現在、認証で説明されています。
キーリングサポート
これは現在、認証で説明されています。
プロキシサーバーの使用¶
PyPIからパッケージをインストールする場合、pip はインターネットアクセスを必要とし、多くの企業環境では、アウトバウンド HTTP プロキシサーバーが必要です。
pip は、さまざまな方法でプロキシサーバーを介して接続するように構成できます。
--proxy
コマンドラインオプションを使用して、scheme://[user:passwd@]proxy.server:port
の形式でプロキシを指定します。設定ファイルで
proxy
を使用します。標準の環境変数
http_proxy
、https_proxy
およびno_proxy
を設定します。環境変数
PIP_USER_AGENT_USER_DATA
を使用して、pip のリクエストで使用されるユーザーエージェント変数に JSON エンコードされた文字列を含めます。
要件ファイル¶
「要件ファイル」とは、次のように pip install を使用してインストールする項目のリストを含むファイルです。
python -m pip install -r requirements.txt
py -m pip install -r requirements.txt
ファイルの形式の詳細はこちらをご覧ください: 要件ファイル形式。
論理的には、要件ファイルは、pip install 引数をファイルに配置したリストにすぎません。ファイル内の項目が pip によって特定の順序でインストールされることに依存しないでください。
要件ファイルは、ローカルファイルに加えて、http://example.com/requirements.txtなどの URL 経由で提供することもできるため、一元的な場所に保存および提供できます。
実際には、要件ファイルには 4 つの一般的な用途があります
要件ファイルは、pip freezeの結果を保持するために使用され、再現可能なインストールを実現することを目的としています。この場合、要件ファイルには、
pip freeze
を実行したときにインストールされたすべての固定バージョンが含まれています。python -m pip freeze > requirements.txt python -m pip install -r requirements.txt
py -m pip freeze > requirements.txt py -m pip install -r requirements.txt
要件ファイルは、pip が依存関係を適切に解決するように強制するために使用されます。pip 20.2 以前には、真の依存関係解決がありませんが、代わりにプロジェクトで見つかった最初の指定を使用するだけです。たとえば、
pkg1
がpkg3>=1.0
を必要とし、pkg2
がpkg3>=1.0,<=2.0
を必要とし、pkg1
が最初に解決される場合、pip はpkg3>=1.0
のみを使用し、pkg2
のニーズと競合するバージョンのpkg3
をインストールしてしまう可能性があります。この問題を解決するには、pkg3>=1.0,<=2.0
(つまり、正しい指定) を他のトップレベルの要件とともに、要件ファイルに直接配置できます。次のようになります。pkg1 pkg2 pkg3>=1.0,<=2.0
要件ファイルは、pip がサブ依存関係の代替バージョンをインストールするように強制するために使用されます。たとえば、要件ファイルの
ProjectA
がProjectB
を必要とするが、最新バージョン (v1.3) にバグがある場合は、次のように pip に以前のバージョンを受け入れるように強制できます。ProjectA ProjectB<1.3
要件ファイルは、バージョン管理にあるローカルパッチで依存関係をオーバーライドするために使用されます。たとえば、PyPI の依存関係
SomeDependency
にバグがあり、アップストリームの修正を待つことができないとします。ソースをクローン/コピーし、修正を加えて、タグsometag
を付けて VCS に配置することができます。要件ファイルでは、次のような行で参照します。git+https://myvcs.com/some_dependency@sometag#egg=SomeDependency
SomeDependency
が以前に要件ファイルでトップレベルの要件であった場合は、その行を新しい行に置き換えてください。SomeDependency
がサブ依存関係である場合は、新しい行を追加してください。
pip は、プロジェクトに埋め込まれた requirements.txt
ファイルを検出することではなく、install_requires メタデータを使用してパッケージの依存関係を決定することを明確にすることが重要です。
参考
制約ファイル¶
制約ファイルは、要件がインストールされるかどうかではなく、どのバージョンの要件がインストールされるかを制御するだけの要件ファイルです。構文と内容は、要件ファイルのサブセットであり、いくつかの種類の構文は許可されていません。制約には名前が必要であり、編集可能ではなく、エクストラを指定することはできません。セマンティクスに関しては、1 つの重要な違いがあります。制約ファイルにパッケージを含めても、パッケージのインストールはトリガーされません。
次のように制約ファイルを使用します。
python -m pip install -c constraints.txt
py -m pip install -c constraints.txt
制約ファイルは、インストールするものを正確に把握していない場合に、要件ファイルと同じ理由で使用されます。たとえば、"helloworld" パッケージが環境で動作しないため、ローカルのパッチが適用されたバージョンがあるとします。インストールするいくつかのパッケージは "helloworld" に依存し、いくつかのパッケージは依存しません。
パッチが適用されたバージョンが一貫して使用されるようにする1つの方法は、インストールするすべてのものの依存関係を手動で監査し、「helloworld」が存在する場合は、そのものをインストールするときに使用する requirements ファイルを作成することです。
制約ファイルはより良い方法を提供します。組織全体で単一の制約ファイルを作成し、それをどこでも使用します。インストールされるものが「helloworld」のインストールを必要とする場合、制約ファイルで指定された固定バージョンが使用されます。
制約ファイルのサポートは pip 7.1 で追加されました。20.3 (2020) での pip 依存関係解決の変更点では、以前の実装にあったいくつかのドキュメント化されていない、サポートされていない癖を取り除き、制約ファイルをパッケージのグローバルな(バージョン)制限を指定するだけの方法にまで簡略化するという、かなり包括的な見直しを行いました。
requirements ファイルと同様に、制約ファイルも URL (例: http://example.com/constraints.txt) を介して提供できるため、組織は集中管理された場所に保存して提供できます。
Wheelからのインストール¶
「Wheel」は、ソースアーカイブからビルドおよびインストールするよりもインストールを大幅に高速化できる、ビルド済みのアーカイブ形式です。詳細については、仕様を参照してください。
pip は、利用可能な場合は Wheel を優先します。これを無効にするには、--no-binary フラグを pip install で使用します。
適切な Wheel が見つからない場合、pip はデフォルトでソースアーカイブを探します。
wheel アーカイブから直接インストールするには
python -m pip install SomePackage-1.0-py2.py3-none-any.whl
py -m pip install SomePackage-1.0-py2.py3-none-any.whl
wheel の provides_extras
メタデータで提供されているオプションの依存関係を含めるには、インストール対象名の周りに引用符を追加する必要があります
python -m pip install './somepackage-1.0-py2.py3-none-any.whl[my-extras]'
py -m pip install './somepackage-1.0-py2.py3-none-any.whl[my-extras]'
注意
将来的には、path[extras]
構文は非推奨になる可能性があります。可能な場合は常に、標準構文を使用することをお勧めします。
Wheel が利用できない場合のために、pip はすべての要件と依存関係の Wheel を構築するための便利な方法として pip wheel を提供しています。
pip wheel を使用するには、使用する setuptools 拡張機能「bdist_wheel」を提供するwheel パッケージをインストールする必要があります。
要件とすべての依存関係の Wheel をローカルディレクトリにビルドするには
python -m pip install wheel
python -m pip wheel --wheel-dir=/local/wheels -r requirements.txt
py -m pip install wheel
py -m pip wheel --wheel-dir=/local/wheels -r requirements.txt
その後、ローカルの Wheel ディレクトリだけを使用して(PyPI からではなく)それらの要件をインストールするには
python -m pip install --no-index --find-links=/local/wheels -r requirements.txt
py -m pip install --no-index --find-links=/local/wheels -r requirements.txt
パッケージのアンインストール¶
pip は、次のようにほとんどのパッケージをアンインストールできます
python -m pip uninstall SomePackage
py -m pip uninstall SomePackage
pip は、新しいバージョンにアップグレードする前に、古いバージョンのパッケージを自動的にアンインストールします。
詳細と例については、pip uninstall リファレンスを参照してください。
パッケージのリスト表示¶
インストールされているパッケージをリスト表示するには
$ python -m pip list
docutils (0.9.1)
Jinja2 (2.6)
Pygments (1.5)
Sphinx (1.1.2)
C:\> py -m pip list
docutils (0.9.1)
Jinja2 (2.6)
Pygments (1.5)
Sphinx (1.1.2)
古いパッケージをリスト表示し、利用可能な最新バージョンを表示するには
$ python -m pip list --outdated
docutils (Current: 0.9.1 Latest: 0.10)
Sphinx (Current: 1.1.2 Latest: 1.1.3)
C:\> py -m pip list --outdated
docutils (Current: 0.9.1 Latest: 0.10)
Sphinx (Current: 1.1.2 Latest: 1.1.3)
インストールされているパッケージの詳細を表示するには
$ python -m pip show sphinx
---
Name: Sphinx
Version: 1.1.3
Location: /my/env/lib/pythonx.x/site-packages
Requires: Pygments, Jinja2, docutils
C:\> py -m pip show sphinx
---
Name: Sphinx
Version: 1.1.3
Location: /my/env/lib/pythonx.x/site-packages
Requires: Pygments, Jinja2, docutils
パッケージの検索¶
pip は、pip search
コマンドを使用して PyPI でパッケージを検索できます
python -m pip search "query"
py -m pip search "query"
クエリは、すべてのパッケージの名前と概要を検索するために使用されます。
詳細と例については、pip search リファレンスを参照してください。
設定
これは 設定 で説明されています。
設定ファイル
これは 設定 で説明されています。
環境変数
これは 設定 で説明されています。
設定の優先順位
これは 設定 で説明されています。
コマンド補完¶
pip には、bash、zsh、fish でのコマンドライン補完のサポートが付属しています。
bash の設定
python -m pip completion --bash >> ~/.profile
zsh の設定
python -m pip completion --zsh >> ~/.zprofile
fish の設定
python -m pip completion --fish > ~/.config/fish/completions/pip.fish
powershell の設定
python -m pip completion --powershell | Out-File -Encoding default -Append $PROFILE
または、シェルの eval 関数で completion
コマンドの結果を直接使用できます。たとえば、スタートアップファイルに以下を追加します
eval "`pip completion --bash`"
ローカルパッケージからのインストール¶
場合によっては、PyPI とのトラフィックなしで、ローカルパッケージからのみインストールしたい場合があります。
まず、要件を満たすアーカイブをダウンロードします
python -m pip download --destination-directory DIR -r requirements.txt
py -m pip download --destination-directory DIR -r requirements.txt
pip download
は、PyPI からダウンロードしようとする前に、まず wheel キャッシュを検索することに注意してください。要件を一度もインストールしたことがない場合は、それらのアイテムの wheel キャッシュはありません。その場合、要件の一部が PyPI から wheel として提供されず、wheel が必要な場合は、代わりにこれを実行してください
python -m pip wheel --wheel-dir DIR -r requirements.txt
py -m pip wheel --wheel-dir DIR -r requirements.txt
次に、ローカルからのみインストールするには、次のように --find-links と --no-index を使用します
python -m pip install --no-index --find-links=DIR -r requirements.txt
py -m pip install --no-index --find-links=DIR -r requirements.txt
「必要な場合のみ」再帰的アップグレード¶
pip install --upgrade
には、pip が依存関係のアップグレードをどのように処理するかを制御する --upgrade-strategy
オプションが追加されました。サポートされているアップグレード戦略は2つあります
eager
: 新しい親要件をまだ満たしているかどうかに関係なく、すべての依存関係をアップグレードしますonly-if-needed
: 新しい親要件を満たしていない場合にのみ、依存関係をアップグレードします
デフォルトの戦略は only-if-needed
です。これは、競合する依存関係をアップグレードする際の eager
の破壊的な性質のため、pip 10.0 で変更されました。
--upgrade
は直接の要件(コマンドラインまたは requirements ファイルで指定されたものなど)に影響し、--upgrade-strategy
は間接的な要件(直接の要件の依存関係)に影響することに注意することが重要です。
たとえば、SomePackage
に依存関係 SomeDependency
があり、両方ともすでにインストールされているが、利用可能な最新バージョンではないとします
pip install SomePackage
: 既存のSomePackage
またはSomeDependency
をアップグレードしません。pip install --upgrade SomePackage
:SomePackage
はアップグレードしますが、SomeDependency
はアップグレードしません(最小要件が満たされていない場合を除く)。pip install --upgrade SomePackage --upgrade-strategy=eager
:SomePackage
とSomeDependency
の両方をアップグレードします。
歴史的なメモとして、only-if-needed
の動作を得るための以前の「修正」は次のとおりでした
python -m pip install --upgrade --no-deps SomePackage
python -m pip install SomePackage
py -m pip install --upgrade --no-deps SomePackage
py -m pip install SomePackage
eager
アップグレードの動作に対するより安全な代替手段として、upgrade-all
コマンドの提案が検討されています。
ユーザーインストール¶
Python 2.6 では、インストールの「ユーザー方式」が導入されました。これは、すべての Python ディストリビューションがユーザー固有の代替インストール場所をサポートすることを意味します。各 OS のデフォルトの場所は、site.USER_BASE 変数の Python ドキュメントで説明されています。このインストールモードは、pip install
に --user オプションを指定することでオンにできます。
さらに、「ユーザー方式」は、PYTHONUSERBASE
環境変数を設定することでカスタマイズできます。これにより、site.USER_BASE
の値が更新されます。
site.USER_BASE
が '/myappenv' にカスタマイズされた環境に「SomePackage」をインストールするには、以下を実行します
export PYTHONUSERBASE=/myappenv
python -m pip install --user SomePackage
set PYTHONUSERBASE=c:/myappenv
py -m pip install --user SomePackage
pip install --user
は4つのルールに従います
グローバルにインストールされたパッケージが python パスにあり、インストール要件と競合する場合、それらは無視され、アンインストールされません。
グローバルにインストールされたパッケージが Python パス上にあり、それがインストール要件を満たしている場合、pip は何もせず、その要件が満たされていると報告します(
--system-site-packages
virtualenv にパッケージをインストールする際にグローバルパッケージが要件を満たすことができるのと同様です)。pip は、
--no-site-packages
virtualenv(つまり、デフォルトの種類の virtualenv)では--user
インストールを実行しません。これは、ユーザーサイトが Python パス上にないためです。インストールは無意味になります。--system-site-packages
virtualenv では、pip は virtualenv の site-packages 内のパッケージと競合するパッケージをインストールしません。--user インストールは sys.path の優先順位がなく、無意味になります。
ルールをより明確にするために、いくつかの例を以下に示します。
--no-site-packages
virtualenv(つまり、デフォルトの種類)内からの場合
$ python -m pip install --user SomePackage
Can not perform a '--user' install. User site-packages are not visible in this virtualenv.
C:\> py -m pip install --user SomePackage
Can not perform a '--user' install. User site-packages are not visible in this virtualenv.
SomePackage==0.3
が virtualenv に既にインストールされている --system-site-packages
virtualenv 内からの場合
$ python -m pip install --user SomePackage==0.4
Will not install to the user site because it will lack sys.path precedence
C:\> py -m pip install --user SomePackage==0.4
Will not install to the user site because it will lack sys.path precedence
グローバルに SomePackage
がインストールされていない実際(グローバル)の Python 内からの場合
$ python -m pip install --user SomePackage
[...]
Successfully installed SomePackage
C:\> py -m pip install --user SomePackage
[...]
Successfully installed SomePackage
グローバルに SomePackage
がインストールされているが、最新バージョンではない実際(グローバル)の Python 内からの場合
$ python -m pip install --user SomePackage
[...]
Requirement already satisfied (use --upgrade to upgrade)
$ python -m pip install --user --upgrade SomePackage
[...]
Successfully installed SomePackage
C:\> py -m pip install --user SomePackage
[...]
Requirement already satisfied (use --upgrade to upgrade)
C:\> py -m pip install --user --upgrade SomePackage
[...]
Successfully installed SomePackage
グローバルに SomePackage
がインストールされており、かつ最新バージョンである実際(グローバル)の Python 内からの場合
$ python -m pip install --user SomePackage
[...]
Requirement already satisfied (use --upgrade to upgrade)
$ python -m pip install --user --upgrade SomePackage
[...]
Requirement already up-to-date: SomePackage
# force the install
$ python -m pip install --user --ignore-installed SomePackage
[...]
Successfully installed SomePackage
C:\> py -m pip install --user SomePackage
[...]
Requirement already satisfied (use --upgrade to upgrade)
C:\> py -m pip install --user --upgrade SomePackage
[...]
Requirement already up-to-date: SomePackage
# force the install
C:\> py -m pip install --user --ignore-installed SomePackage
[...]
Successfully installed SomePackage
再現性の確保
これは 再現可能なインストール で説明されています。
競合する依存関係の修正
これは 依存関係の解決 で説明されています。
プログラムから pip を使用する¶
前述したように、pip はコマンドラインプログラムです。Python で実装されているため、import pip
を介して Python コードから利用できますが、pip の内部 API をこの方法で使用してはなりません。これにはいくつかの理由があります。
pip のコードは、プログラムのグローバルな状態を単独で制御していることを前提としています。pip は、ログシステムの構成や、ユーザーコードが影響を受ける可能性を考慮せずに、標準 IO ストリームの値などを管理します。
pip のコードはスレッドセーフではありません。スレッドで pip を実行した場合、コードまたは pip のいずれかが期待どおりに動作する保証はありません。
pip は、作業が完了するとプロセスが終了することを前提としています。その後も他のコードが実行され続ける可能性を処理する必要がないため、たとえば、同じプロセスで pip を 2 回呼び出すと問題が発生する可能性があります。
これは、pip の開発者が、原則として pip をライブラリとして使用するという考えに反対しているという意味ではありません。これは、そのように作成されておらず、上記の問題をすべて処理し、使用可能で堅牢で安定した API を設計して、pip の複数のリリースで利用可能であることを保証する必要があり、ライブラリとして使用するために内部を再設計するのは大変な作業になるでしょう。また、現在そのようなタスクを検討するためのリソースもありません。
実際には、これは pip 内のすべてが実装の詳細と見なされることを意味します。インポート名が pip
であるという事実でさえ、予告なしに変更される可能性があります。できるだけ変更しないように努めますが、すべての内部 API は、いつでも、いかなる理由でも変更される可能性があります。また、通常は、サポートされていない方法で pip を使用した結果として生じる問題を修正しないことも意味します。
また、実行中の Python プロセスで sys.path
にパッケージをインストールすることは、慎重に行う必要があることに注意してください。インポートシステムは特定のデータをキャッシュし、プログラムの実行中に新しいパッケージをインストールすると、常に期待どおりに動作するとは限りません。実際には問題はめったにありませんが、注意すべき点です。
上記すべてを踏まえて、プログラム内から pip を実行したいと判断した場合に利用できるオプションについて説明する価値があります。最も信頼性が高く、完全にサポートされているアプローチは、pip をサブプロセスで実行することです。これは、標準の subprocess
モジュールを使用して簡単に行えます。
subprocess.check_call([sys.executable, '-m', 'pip', 'install', 'my_package'])
出力をさらに処理する場合は、モジュールの他の API のいずれかを使用します。ここでは、インストールされたパッケージを requirements 形式で出力する freeze を使用しています。
reqs = subprocess.check_output([sys.executable, '-m', 'pip', 'freeze'])
ダウンロードの進行状況をプログラムで監視するには、--progress-bar=raw
オプションを使用します。これにより、Progress CURRENT of TOTAL
の形式で stdout に行が出力されます。CURRENT
と TOTAL
は整数で、単位はバイトです。実際の合計が不明な場合、TOTAL
は 0
に設定されます。pip の出力の特定の形式は、将来のバージョンで同じであるとは保証されないことに注意してください。
pip のコマンドライン機能を使用するのではなく、Python パッケージ、そのメタデータ、または PyPI を操作するコードを実装しようとしている場合は、このタイプの機能を提供する、サポートされている他のパッケージを検討する必要があります。検討できるいくつかの例を以下に示します。
packaging
- 標準のパッケージメタデータ(バージョン、要件など)を操作するユーティリティsetuptools
(特にpkg_resources
) - ユーザーがシステムにインストールしたパッケージをクエリするための関数。distlib
- パッケージングおよび配布ユーティリティ(PyPI との対話のための関数を含む)。
20.3(2020)での pip 依存関係リゾルバーの変更¶
pip 20.3 には新しい依存関係リゾルバーがあり、Python 3 ユーザーに対してデフォルトでオンになっています。(pip 20.1 および 20.2 には、オプションのユーザーフラグの背後に隠された、新しい依存関係リゾルバーのプレリリースバージョンが含まれていました。)移行ガイド、レガシーリゾルバーの呼び出し方、および非推奨のタイムラインについては、以下をお読みください。また、視聴できる2 分間のビデオ説明も作成しました。
テスターのフィードバックに応じて、pip 依存関係リゾルバーの改善を継続します。 リゾルバーテストアンケートを通じてフィードバックをお寄せください。
注意すべきこと¶
このリリースの大きな変更は、pip 内の pip 依存関係リゾルバーに対するものです。
コンピューターは、ソフトウェアをインストールする正しい順序を知る必要があります(「x
をインストールするには、最初に y
をインストールする必要がある」)。そのため、Python プログラマーがパッケージとしてソフトウェアを共有する場合、それらのインストールの前提条件を正確に記述する必要があり、pip は、競合する指示を取得している難しい状況をナビゲートする必要があります。この新しい依存関係リゾルバーにより、pip はその難しいロジックの処理が向上し、pip が使いやすくなり、トラブルシューティングが容易になります。
リゾルバーの最も重要な変更点は次のとおりです。
矛盾を減らします: 相互に矛盾するパッケージの組み合わせをインストールしなくなります。古いバージョンの pip では、pip が、インストールされている別のパッケージの宣言された要件を満たさないパッケージをインストールする可能性があります。たとえば、pip 20.0 では、
pip install "six<1.12" "virtualenv==20.0.2"
は間違ったことを実行し、six==1.11
を「正常に」インストールします。これは、virtualenv==20.0.2
がsix>=1.12.0,<2
を要求しているにもかかわらずです (ここで定義)。新しいリゾルバーは、代わりに、その入力を受け取ると、インストールを完全に拒否します。厳密になります。互換性のない要件を持つ 2 つのパッケージをインストールするように pip に要求した場合、pip は(以前のバージョンで行っていたように、破損した組み合わせをインストールするのではなく)拒否します。
したがって、互換性のない要件の組み合わせを pip に強制的に処理させるための回避策を使用していた場合は、パッケージの根本的な問題を修正するのに適した時期です。これは、pip が今後はより厳密になるためです。
これはまた、pip install
コマンドを実行すると、pip はそのコマンドでインストールしているパッケージのみを考慮し、既にインストールされているパッケージを壊す可能性があることも意味します。環境が常に一貫しているとは保証されません。pip install x
を実行し、次に pip install y
を実行する場合、y
のバージョンが、単一のコマンドで pip install x y
を実行した場合と異なる可能性があります。この動作を変更することを検討しています(#7744)および pip の動作がどうあるべきかについての皆様の考えをお聞かせください。競合を引き起こすアップグレードに関するアンケートにお答えください。
また、制約ファイル、編集可能なインストール、および関連機能のサポートも変更しています。かなり包括的な見直しを行い、制約ファイルをパッケージのグローバルな(バージョン)制限を指定する方法のみに絞り込んだため、これまで許可されていた一部の組み合わせではエラーが発生するようになりました。具体的には
制約は、既存の要件を上書きしません。単に、リゾルバーへの入力として表示されるバージョンを制約するだけです(#9020を参照)。
編集可能な要件(
-e .
)を提供しても、pip はバージョン指定子または制約を無視せず(#8076を参照)、固定された要件とローカルディレクトリの間に競合がある場合、pip は両方を満たすバージョンが見つからないことを示します(#8307を参照)。ハッシュチェックモードでは、すべての要件がバージョンの
==
一致として指定されている必要があり、制約と組み合わせてうまく動作しない場合があります(#9020 および #8792を参照)。制約を満たすために必要な場合は、追加のコマンドラインオプションを必要とせずに、pip はパッケージを再インストールし、アップグレードまたはダウングレードします(#8115 および インストールプロセスを制御するオプションを参照)。
リンクは制約として許可されていません(#8253を参照)。
制約に extras を含めることはできません(#6628を参照)。
私たちのPython 2 サポートポリシーに従い、Python 2 を使用している pip 20.3 のユーザーは、デフォルトでレガシーリゾルバーを使用します。Python 2 ユーザーはできるだけ早く Python 3 にアップグレードする必要があります。pip 21.0(2021年1月)では、pip は Python 2 のサポートを完全に打ち切りました。
アップグレードと移行方法¶
python -m pip install --upgrade pip
を使用してpip 20.3 をインストールします。pip check
を実行して現在の環境を検証します。これにより、インストール済みのパッケージのセットに矛盾があるかどうかが報告されます。クリーンなインストールを行うことで、新しいリゾルバーで問題が発生する可能性が大幅に低くなります(また、現在の環境に隠された問題に対処できる可能性があります!)。pip check
を実行して、解決できない問題が発生した場合は、issue tracker またはチャットでヘルプを求めてください。新しいバージョンの pip をテストする.
pip のテストスイートでできるだけ多くのケースをカバーするように努めてきましたが、さまざまなワークフローやビルドプロセスで pip を使用しているユーザーがいることを十分に認識しており、皆様のご協力なしには、それらすべてをカバーすることはできません。
ソフトウェアのインストールに pip を使用している場合は、新しいリゾルバーを試して、
pip install
で動作するかどうかをお知らせください。試していただきたいことは次のとおりです。複数のパッケージを同時にインストールする
requirements.txt
ファイルを使用して環境を再作成するpip install --force-reinstall
を使用して、期待どおりに動作するかどうかを確認する制約ファイルを使用する
以下の「特に注意してテストする設定」と「試す例」
pip が依存関係をインストールすることに依存するビルドパイプラインがある場合は、新しいリゾルバーが必要な動作をしていることを確認してください。
新しいリゾルバーを使用して、プロジェクトの CI (テストスイート、ビルドプロセスなど) を実行し、問題があればお知らせください。
過去に pip でリゾルバーの問題が発生したことがある場合は、新しいリゾルバーで解決するかどうかを確認し、依存関係の競合への対処を読んでください。また、現在のリゾルバーの制限に対処するために導入した回避策で、新しいリゾルバーに問題がある場合はお知らせください。人々がそのような回避策からスムーズに移行できるようにする必要があります。
pip をラップするツールを開発またはサポートしている場合、または pip を使用して機能の一部を提供している場合は、pip 20.3 での統合をテストしてください。
必要に応じてトラブルシューティングを行い、これらの回避策を試してください。
pip がパッケージのインストールに時間がかかる場合は、依存関係の競合によるバックトラックに pip が費やす時間を短縮する方法について、依存関係の解決のバックトラックをお読みください。
pip に依存関係を実際に解決させたくない場合は、
--no-deps
オプションを使用してください。これは、メタデータで競合していると表示されていても、実際には一緒に動作するパッケージバージョンのセットがある場合に役立ちます。長期的な修正のガイダンスについては、依存関係の競合への対処をお読みください。解決エラーが発生し、根本的な原因を修正している間、回避策が必要な場合は、フラグ
--use-deprecated=legacy-resolver
を使用して、古いリゾルバーの動作を選択できます。これは、pip 21.0 をリリースするまで機能します (「非推奨タイムライン」を参照)。
バグを報告するには、リゾルバーテストアンケートにご協力ください。
特に注意してテストする設定¶
100 個以上のパッケージを含む要件ファイル
複数の要件ファイルを含むインストールワークフロー
ハッシュ(ハッシュチェックモード)またはピン留めされた依存関係(おそらく、
pip-tools
内のpip-compile
からの出力として)を含む要件ファイル制約ファイルの使用
継続的インテグレーション/継続的デプロイメント設定
VCS サポートに従い、あらゆる種類のバージョン管理システム(Git、Subversion、Mercurial、または CVS)からインストールする
ローカルディレクトリにあるソースコードからインストールする
試す例¶
インストール
hacking
pycodestyle
pandas
tablib
elasticsearch
とrequests
を一緒にsix
とcherrypy
を一緒にpip install flake8-import-order==0.17.1 flake8==3.5.0 --use-feature=2020-resolver
pip install tornado==5.0 sprockets.http==1.5.0 --use-feature=2020-resolver
試してください
pip install
pip uninstall
pip check
pip cache
以下について教えてください¶
フィードバックをいただきたい具体的なこと
明らかに、新しいリゾルバーが間違った結果を生成した場合。このようなケースはあまりないことを願っていますが、レガシーリゾルバーを削除する前に、このようなバグをトラップしたいと考えています。
何をすべきか解明できたはずだと考えられるにもかかわらず、リゾルバーがエラーを生成した場合。
要件に問題があるためリゾルバーがエラーを出すが、何が問題なのかを把握するためにはより良い情報が必要な場合。
現在のリゾルバーの問題に対処するための回避策がある場合、新しいリゾルバーではそれらの回避策を削除できますか?ぜひ教えてください!
リゾルバーテストアンケートを通じてお知らせください。
非推奨タイムライン¶
リゾルバーの切り替えは、機能フラグを使用し、リリース頻度に従い、以下のように進める予定です。
pip 20.1: 新しいリゾルバーのアルファ版が利用可能になりました。オプトインで、オプションのフラグ
--unstable-feature=resolver
を使用します。pip はデフォルトでレガシー動作になりました。pip 20.2: 新しいリゾルバーのベータ版が利用可能になりました。オプトインで、フラグ
--use-feature=2020-resolver
を使用します。pip はデフォルトでレガシー動作になりました。pip がデフォルトで新しいリゾルバーを使用するようにしたい pip 20.2 のユーザーは、pip config set global.use-feature 2020-resolver
を実行できます (詳細と、代替のPIP_USE_FEATURE
環境変数オプションについては、issue 8661 を参照)。pip 20.3: pip は Python 3 環境ではデフォルトで新しいリゾルバーになりますが、ユーザーはフラグ
--use-deprecated=legacy-resolver
を使用してオプトアウトして古いリゾルバーの動作を選択できます。Python 2 環境では、pip はデフォルトで古いリゾルバーになり、フラグ--use-feature=2020-resolver
を使用して新しいリゾルバーを使用できます。pip 21.0: pip はデフォルトで新しいリゾルバーを使用し、古いリゾルバーはサポートされなくなります。pip のボランティアメンテナーの可用性に依存するため、削除は未定の期間後になります。私たちのPython 2 サポートポリシーに従い、Python 2 のサポートは削除されます。
この作業は pip ドキュメントに記載されているユーザーに表示される動作を変更しないため、この変更は非推奨ポリシーの対象外です。
注意
レガシーリゾルバーは非推奨であり、サポートされていません。インストールレポートなどの新機能は、レガシーリゾルバーでは機能せず、このリゾルバーは将来のリリースで削除されます。
コンテキストとフォローアップ¶
PSFブログでの発表で説明したように、pipチームは新しい「依存関係リゾルバー」(要件に基づいてインストールするものを解決する pip の部分)を開発中です。
私たちは、#6536でロールアウトを追跡しており、トラフィックの少ないパッケージングに関するアナウンスリストと公式Pythonブログでアナウンスを監視できます。
HTTPS を検証するためのシステムトラストストアの使用
これについては、HTTPS 証明書で説明しています。