Pythonパッケージは多くのディストリビューションのリポジトリでホストされています。読んだ後これチュートリアル、特に「本当にこれを行いますか？」というタイトルのセクションでは、pipを使用しないでシステムリポジトリを使用することを好み、リポジトリにないパッケージをインストールする必要がある場合にのみpipを使用しました。
しかし、これは一貫性のないインストール方法なので、単にpipを使用するのが良いでしょうか？両方の場所で利用可能なパッケージにシステム独自のリポジトリの代わりにpipを使用すると、どのような利点/欠点がありますか？
リンクステータスを含めました
常に標準のDebian / NeuroDebianパッケージを使用する利点は、これらのパッケージが互いに互換性を確保するために慎重にテストされることです。 Debian パッケージは他のライブラリへの依存関係を文書化するため、インストール中に必要なライブラリを常に取得できます。
私はアーチを使用しています。 aptに加えて、他のパッケージ管理システムでも同じですか？
答え1
私の考えでは、Pythonモジュール（システムモジュールでもユーザーモジュールでも）を使用してシステムにインストールすることの主な欠点は、ディストリビューションpipのパッケージ管理システムがそれについて知らないことです。つまり、それを必要とする他のパッケージでは使用されず、後でインストールしようとしている可能性があります（またはアップグレード後にモジュールの1つを使用し始めることもできます）。これにより、pip両方のモジュールのリリース管理が終了します。問題を引き起こす可能性のあるバージョン（私はこの例はまたあります最近の）。したがって、あなたの質問は、最終的にすべてまたは専務の提案です。ただPythonモジュールの場合、pipPythonモジュールを使用するすべてのものに対してディストリビューションのパッケージマネージャを使用できなくなります。
あなたがリンクしたページに提供されている一般的なアドバイスはとても良いです。可能であれば、ディストリビューションパッケージをpipパッケージ化されていないモジュールにのみ使用します。そうする場合は、システム全体ではなくユーザー設定でそれを実行してください。特にモジュール開発の場合は、可能であれば仮想環境を使用してください。特に、アーチでは、問題になる可能性があるディストリビューションでも、古いモジュールによって引き起こされる問題は発生しないでください。仮想環境ではこれを簡単に処理できます。
ディストリビューションのライブラリとモジュールパッケージが主にディストリビューションの他のパッケージで使用するためにパッケージ化されることを考慮することは価値があります。これらのパッケージを持つことは、そのライブラリとモジュールを使用して開発するための良い副作用ですが、これが主なユースケースではありません。
答え2
長い話を短く
pipオブジェクト（ライブラリ、フレームワーク、開発ツール）には（+ virtualenv）を使用してください。あなたのプロジェクト（あなたが開発）を使う- アプリケーションのパッケージマネージャの使用あなた使用（エンドユーザーとして）
開発依存関係
pipPythonでソフトウェアを開発する場合は、ランタイム依存関係、ビルド時間依存性、または自動化されたテスト、および自動化されたコンプライアンスチェックに必要なもの（リンター、スタイルチェッカー、静的型チェッカー）など、プロジェクトのすべての依存関係を使用する必要があります。 ...)
いくつかの理由があります：
- これにより、以下を使用できます。仮想環境異なるプロジェクトの依存関係を互いに分離し（直接またはvirtualenvwrapperやPipenvなどを介して）、「本番で」（ユーザーとして）使用するPythonアプリケーションを可能なエイリアンのいたずら（または単に非互換性）から分離します。引き続き発展してください。
requirements.txtこれにより、ファイル（プロジェクトがアプリケーションの場合）または（プロジェクトがライブラリまたはフレームワークの場合）setup.pyでプロジェクトのすべての依存関係を追跡できます。これはソースコードとともに改訂制御（Gitなど）で確認できるため、どのバージョンのコードがどの依存バージョンに依存するのかを常に知ることができます。- 上記を使用すると、他の開発者が同じLinuxディストリビューションを使用していなくても、他のオペレーティングシステムを使用していなくても、使用されている依存関係がMacおよびWindowsまたは使用しているすべてのデバイスで機能できる場合は、プロジェクトで共同作業できます。
- オペレーティングシステムのパッケージマネージャの自動更新によってコードが破損することは望ましくありません。依存関係を更新する必要がありますが、コードを変更したり更新をロールバックしたりするために選択した時点で意図的に更新する必要があります。 （リビジョン制御システムのコードとともに、依存関係宣言全体を追跡するのは簡単です。）
直接依存関係と間接依存関係を分離する必要があると思う場合（または依存関係の許容可能なバージョンの範囲と実際に使用されているバージョンを区別する必要がある場合は「バージョンの固定」を参照）、pip-toolsおよび/またはPipelinevを見てください。これにより、ビルドの依存関係とテストの依存関係を区別できます。 （ビルド依存関係とランタイム依存関係の違いはおそらくコード化できますsetup.py。）
使用するアプリケーション
一般的なアプリケーションとして使用するものの場合今起こったことPythonで作成するには、オペレーティングシステムのパッケージマネージャを選択してください。これにより、合理的に最新の状態を維持し、パッケージマネージャがインストールした他のものと互換性があるようにすることができます。また、ほとんどのLinuxディストリビューションはマルウェアを配布しないと主張しています。
必要なものがディストリビューションのデフォルトのパッケージリポジトリにない場合は、他のパッケージリポジトリ（debベースのディストリビューションのランチパッドなど）を確認するか、pipとにかく使用できます。後者の場合、システム--user全体ではなくユーザーの自宅にインストールする方法を使用すると、Pythonのインストールが中断される可能性が低くなります。 （一時的またはまれに必要な場合は、virtualenvを使用することもできます。）
答え3
パッケージマネージャを使用するもう1つの理由は、アップデートが自動的に適用されることです。これはセキュリティにとって非常に重要です。 Equifaxで使用されているBeanパッケージがyum-cron-securityを介して自動的に更新された場合、ハッカー攻撃が発生していない可能性があります。
私の個人的な開発ボックスではPipを使用し、本番ではパッケージを使用します。
答え4
一般化する
作業中のモジュールは3つのカテゴリに分類されます。
- これらのサポートプログラムは、オペレーティングシステムパッケージシステムのすべてのユーザーにインストールされます。 （ここにはPythonでプログラミングする人のためのツールとライブラリも含まれています。以下を参照してください。）これを可能にする場合は、オペレーティングシステムパッケージを使用し、
pip必要に応じてシステムディレクトリにインストールできます。 - 特定のユーザーがインストールしたサポートプログラムはそのユーザー自身のためのものであり、Pythonをスクリプト言語で「日常」を使用する特定の側面のためのものです。彼女はこれらのために
pip --userおそらくピエンブまたはPython、同様のツールと戦略。 - 特定のアプリケーションの開発と使用をサポートします。これには
virtualenv（または同様のツール）を使用できます。
ここの各レベルは前のレベルでもサポートできます。たとえば、（2）のユーザーは、オペレーティングシステムパッケージを介してインストールされているPythonインタプリタに頼ることができます。
これについて詳しく説明すると、次のようになります。
システムプログラムとソフトウェアパッケージ
「ただ実行」したいPythonで書かれたプログラムは簡単です。オペレーティングシステムのインストールツールを使用して必要なものをすべてインポートすることは、Python以外のプログラムと変わりません。これは、ユーザーが依存関係を理解し、理想的にはそうでないホストでこれを処理する方法を知っている限り、コンピュータのユーザーが依存し始めることができるPythonツール/ライブラリを導入できます。これらの依存関係を提供することは問題ではありません。
この依存関係の一般的で簡単な例は、RH / CentOS 7とそのほとんど（すべてではない）Ubuntuインストール（Python 2で実行されている限り）でうまく機能するいくつかのプライベートスクリプトです~/.local/bin/。#!/usr/bin/env pythonデフォルトのDebianインストールまたはWindowsで実行されます。私は私の個人的な環境がオペレーティングシステムパッケージに多くの依存関係を持っているのが好きではありませんが（私はさまざまなオペレーティングシステムで作業しています）、それが私が持っていないまれなケースではかなり受け入れやすいと思います。 PythonシステムでホストシステムからPythonをインポートできない場合、バックアップ計画は以下の説明に従ってユーザーシステムを使用することです。
システムPythonインタプリタを使用している人は通常システムによって異なりますpip3。ここでは、一般にシステムの依存関係に対して線を引きます。それ以降のすべてのタスクはvirtualenv私が直接処理します。 （例えば、私標準アクティベーションスクリプトパス内のすべてに依存しますpip3が、作成中の仮想環境をブートストラップするために独自のコピーをダウンロードします。pipvirtualenv
つまり、場合によっては、より多くの開発環境を提供することが完全に合理的である可能性があります。システムバージョンのパッケージを使用したい複雑なパッケージ（DBMSなど）にPythonインターフェースを接続することができます。それと通信するために使用します。あるいは、Pythonに似た基本的な開発環境を使用して複数のホストにデプロイし、標準のシステムパッケージを使用して自動化するのが最も簡単な方法です。
ユーザー「毎日」プログラムとパッケージ
ユーザーは最初に仮想環境を作成するのを助けたいので、仮想環境に適していないPythonライブラリやプログラムを持っている可能性があります（例：仮想環境ラッパー）またはPython以外の操作を実行する場合でも、通常はコマンドラインで使用します。これらのツールのシステムバージョンをインストールする能力がある場合でも、独自のツールをインストールする方が便利です（たとえば、最新バージョンのツールとその依存関係を使用したいため）。
一般に、pip --user人々はこれに使用しますが、いくつかの依存関係（Pythonインタプリタ自体など）にはより多くのものが必要です。ピエンブそしてPythonプライベートインタプリタを構築するのに役立ちます（プライマリインタプリタとしてインストールするか他のインタプリタとしてインストールするか）~/.local/bin。もちろん、開発ライブラリが利用可能な場合は、常にソースから「手動で」構築できます。
私はここに最小限のインストールを試してみました：virtualenvwrapper（私はそれをたくさん使うので）そしておそらく最新バージョンのpipかもしれません。多くのホストで使用するために作成するプライベートスクリプトの場合、標準ライブラリやPython 3以外の項目に依存しないようにします。 （しかし、ますます個人的なスクリプトをPythonに移動しながら、これをどれだけ長く維持できるかを見てみましょう。）
独立したアプリケーション開発とランタイム環境
これは一般的なvirtualenvです。開発の場合、ほとんど常に virtualenv を使用してシステム依存関係を使用しないことを確認したり、複数の virtualenv を使用してさまざまな Python バージョンをテストしたりすることがよくあります。
このような仮想環境は、ユーザー環境を汚染したくない依存性の高いアプリケーションにも適しています。たとえば、私は通常virtualenvを設定して実行します。木星ノートパソコンなど。