Pythonパッケージを処理するためのPip vs Package Manager
Pythonパッケージは、多くのディストリビューションのリポジトリで頻繁にホストされています。 this チュートリアルを読んだ後、特に「これを本当に実行しますか」というタイトルのセクションで、pipの使用を避け、システムリポジトリの使用を推奨しました。パッケージをインストールする必要がない場合にのみ、pipを使用しました。リポジトリ内。
ただし、これは一貫性のないインストール方法であるため、pipのみを使用する方が良いでしょうか？両方の場所で利用可能なパッケージについて、システムの独自のリポジトリを介してpipを使用することの利点/批判者は何ですか？
私が含めたリンクは状態
常に標準のDebian/NeuroDebianパッケージを使用する利点は、パッケージが互いに互換性があるように慎重にテストされていることです。 Debianパッケージは他のライブラリとの依存関係を記録するため、インストールの一部として必要なライブラリを常に入手できます。
私はArchを使用しています。これは、apt以外の他のパッケージ管理システムにも当てはまりますか？
pipを使用してシステムにPythonモジュールをシステムモジュールとして、またはユーザーモジュールとしてインストールする場合の最大の欠点は、ディストリビューションのパッケージ管理システムがそれらを認識しないことです。これは、それらを必要とし、将来インストールする可能性がある（またはアップグレード後にこれらのモジュールの1つを使用し始める可能性がある）他のパッケージには使用されないことを意味します。その後、モジュールのpip-バージョンとディストリビューション管理バージョンの両方が作成されるため、問題が発生する可能性があります（私は これの別のインスタンス に最近遭遇しました）。したがって、あなたの質問は、すべてか無かの命題になってしまいます。Pythonモジュールにonlypipを使用すると、ディストリビューションのパッケージマネージャーを使用できなくなりますPythonモジュールを使用したいすべての場合...
リンク先のページに記載されている一般的なアドバイスは非常に優れています。ディストリビューションのパッケージをできるだけ使用し、パッケージ化されていないモジュールにはpipのみを使用してください。そうする場合は、システムではなくユーザー設定で使用してください-ワイド。特にモジュール開発では、可能な限り仮想環境を使用します。特にArchでは、古いモジュールが原因で発生する問題に遭遇すべきではありません。それが問題になる可能性のあるディストリビューションでも、仮想環境はそれを非常に簡単に処理します。
ディストリビューションのライブラリとモジュールパッケージは、主にディストリビューション内の他のパッケージを使用するためにパッケージ化されていることを常に考慮する価値があります。それらを配置することは、これらのライブラリとモジュールを使用した開発にとって素晴らしい副作用ですが、それは主なユースケースではありません。
TL; DR
- ものに
pip（+ virtualenv）を使用（ライブラリ、フレームワーク、おそらく開発ツール）your projects（開発したもの） - アプリケーションにパッケージマネージャーを使用あなた使用（エンドユーザーとして）
開発の依存関係
Pythonでソフトウェアを開発している場合は、プロジェクトのすべての依存関係にpipを使用する必要があります。実行時の依存関係、ビルド時の依存関係、または自動テストと自動コンプライアンスチェックに必要なもの（リンター、スタイルチェッカー、静的型チェッカー...）
これにはいくつかの理由があります。
- これにより、virtualenvを使用して（直接またはvirtualenvwrapperまたはpipenvまたは他の手段を通じて）、異なるプロジェクトの依存関係を互いに分離し、pythonアプリケーションを分離することができます。開発中である可能性のあるすべてのエキゾチックなシェナンガン（または単に非互換性）から（ユーザーとして）「製造中」を使用します。
- これにより、
requirements.txt（プロジェクトがアプリケーションの場合）またはsetup.py（プロジェクトがライブラリまたはフレームワークの場合）ファイルでプロジェクトのすべての依存関係を追跡できます。これは、ソースコードと共にリビジョン管理（Gitなど）にチェックインできるため、コードのどのバージョンが依存関係のどのバージョンに依存しているかを常に知ることができます。 - 上記により、他の開発者が同じLinuxディストリビューションを使用していない場合や、同じオペレーティングシステムを使用していない場合でも、プロジェクトで共同作業を行うことができます（使用された依存関係がMacとWindowsでも利用できる場合、または使用しているものすべて）
- オペレーティングシステムのパッケージマネージャーを自動更新してコードを壊したくない。依存関係を更新する必要がありますが、コードを修正したり、更新をロールバックしたりできるように、意識的に、場合によっては選択する必要があります。 （リビジョン管理システムで完全な依存関係の宣言をコードと一緒に追跡すると、これは簡単です。）
直接依存関係と間接依存関係を分離する必要があると思われる場合（または依存関係の許容バージョン範囲と使用される実際のバージョンを区別する場合は、「バージョンの固定」を参照）、pip-toolsやpipenvを調べます。これにより、ビルドとテストの依存関係を区別することもできます。 （ビルドとランタイムの依存関係の違いは、おそらくsetup.pyでエンコードできます）
使用するアプリケーション
通常のアプリケーションとして使用し、発生するだけでPythonで作成する場合は、オペレーティングシステムのパッケージマネージャーを使用してください。パッケージマネージャーによってインストールされた他のものと相応に最新で互換性があることを確認します。ほとんどのLinuxディストリビューションは、マルウェアを配布しないと断言します。
必要なものがディストリビューションのデフォルトのパッケージリポジトリで利用できない場合は、追加のパッケージリポジトリ（debベースのディストリビューションのランチパッドなど）をチェックアウトするか、とにかくpipを使用できます。後者の場合は、システム全体ではなく--userを使用してユーザーの家にインストールします。これにより、Pythonのインストールを中断する可能性が低くなります。一時的またはまれに、virtualenvを使用することもできます。）
パッケージマネージャーを使用するもう1つの理由は、更新プログラムが自動的に適用されることです。これはセキュリティにとって重要です。 Equifaxが使用するBeanパッケージがyum-cron-securityを介して自動的に更新された場合は、ハッキングが行われていない可能性があります。
私の個人的な開発ボックスではPipを使用しています。製品版ではパッケージを使用しています。
作成中のコードで使用するpythonパッケージのインストールについて話している場合は、pipを使用します。
作業しているプロジェクトごとに、仮想環境を作成し、pipを使用してそのプロジェクトに必要なもののみをインストールします。このようにして、使用するすべてのライブラリを一貫した方法でインストールします。ライブラリは含まれているため、パッケージマネージャーを介してインストールするものに干渉しません。
pythonコードをリリースする予定の場合は、通常、setup.pyまたはrequirements.txtをプロジェクトに追加すると、pipはすべての依存関係を自動的に取得できます。そのプロジェクトの仮想環境を簡単に作成または再作成できるようにします。
概要
扱っているモジュールには、3つの一般的なカテゴリがあります。
- OSパッケージシステムを使用するすべてのユーザー向けにインストールされたサポートプログラム。 （これには、Pythonでプログラミングする人が使用するツールやライブラリが含まれることもあります。以下を参照してください。）これらの場合、可能な場合はOSパッケージを使用し、必要に応じて
pipをシステムディレクトリにインストールします。 - 特定のユーザーが自分で使用するためにのみ、およびスクリプト言語としてPythonを「日常的に」使用する特定の側面のためにインストールされるサポートプログラム。これらのために、彼女は
pip --user、おそらく pyenv または pythonz 、および類似のツールと戦術を使用します。 - 特定のアプリケーションの開発と使用をサポートするもの。これらの場合、
virtualenv（または同様のツール）を使用します。
ここの各レベルは、前のレベルからサポートを得ている可能性もあります。たとえば、（2）のユーザーは、OSパッケージを介してインストールされたPythonインタープリターに依存している可能性があります。
これについてもう少し詳しく説明します。
システムプログラムとパッケージ
「実行」したいPythonで記述されたプログラムは簡単です。OSインストールツールを使用して、必要なものをすべて導入させます。これはPython以外のプログラムと同じです。これにより、Pythonツール/ライブラリ（Pythonインタープリター自体など）が組み込まれ、マシンのユーザーが依存し始める可能性があります。依存関係を理解しており、理想的には、それらの依存関係を提供しないホストでそれを処理するための代替手段を知っている限り、これは問題ではありません。
このような依存関係の一般的で単純な例は、~/.local/bin/で始まる#!/usr/bin/env pythonで始まる個人用スクリプトの一部です。これらは、RH/CentOS 7およびほとんど（すべてではない）Ubuntuインストールで（Python 2で実行されている限り）正常に動作します。基本的なDebianインストールの下やWindows上にはありません。 OSパッケージへの依存が大きい個人環境（多くの異なるOSで作業しています）が嫌いなのと同じように、このようなものはかなり受け入れられます。システムがなくPythonシステムを取得できない珍しいホストでのバックアップ計画は、以下で説明するように、ユーザーシステムを使用することです。
システムpythonインタープリターを使用している人々は、通常、システムpip3にも依存しています。これが、通常、システムの依存関係に線を引くところです。 virtualenv以降のすべてのことを自分で扱います。 （たとえば、my 標準のアクティブ化スクリプト は、パス内のpip3またはpipに依存しますが、virtualenvの独自のコピーをbootstrap作成する仮想環境。
とはいえ、開発環境をさらに利用可能にすることが完全に合理的である状況がおそらくあるでしょう。システムバージョンを使用する複雑なパッケージ（DBMSなど）へのPythonインターフェイスがあり、システムに特定のPythonライブラリコードを選択させるのが最善であると感じる場合話をするのに使います。または、Pythonクラスの基本的な開発環境で多数のホストをデプロイしていて、標準のシステムパッケージで自動化するのが最も簡単な場合があります。
ユーザーの「日常的な」プログラムとパッケージ
ユーザーがPythonライブラリまたはプログラムを持っている可能性があるため、仮想環境の作成を最初から支援したいと考えているため（例 virtualenvwrapper ）、またはPython以外の作業を行っているときでも、コマンドラインから一般的に使用するもの。これらのシステムバージョンをインストールする機能があっても、独自にインストールする方が快適な場合があります（たとえば、ツールの最新バージョンとその依存関係を使用したいため）。
一般的にpip --userはこれに使用されますが、Pythonインタープリター自体などの特定の依存関係では、それより少し多くのものが必要です。 pyenv と pythonz は、パーソナルインタープリターを構築するのに役立ちます（~/.local/binにインストールしてデフォルトのインタープリターにするかどうかにかかわらず）。もちろん、いつでもビルドできます "開発ライブラリが利用可能な場合は、ソースから」.
私はここにインストールされている最小限のセットを維持しようとします：virtualenvwrapper（私は常にそれを使用しているためです）とおそらく最新バージョンのpip。私は、多くのホスト間で使用されるように記述した個人用スクリプトの標準ライブラリまたはPython 3以外の依存関係を回避しようとします。 （ただし、これらの個人用スクリプトをPythonに移行するにつれて、それをどれだけ長く我慢できるかがわかります。）
独立したアプリケーション開発環境とランタイム環境
これは通常のvirtualenvです。開発では、ほとんどの場合、virtualenvを使用して、システムの依存関係を使用していないことを確認するか、多くの場合、異なるPythonバージョンに対してテストするために複数を使用する必要があります。
これらの仮想環境は、ユーザー環境の汚染を回避する必要がある多くの依存関係があるアプリケーションにも適しています。たとえば、通常は Jupyter ノートブックなどを実行するためにvirtualenvを設定します。