Pythonパッケージは、多くのディストリビューションのリポジトリで頻繁にホストされています。このチュートリアルを読んだ後、具体的には「これを本当にやりたいですか」というタイトルのセクションで、私はpipの使用を避け、システムリポジトリの使用を好みました。

ただし、これは一貫性のないインストール方法であるため、pipのみを使用する方が良いでしょうか？両方の場所で利用可能なパッケージのために、システムの独自のリポジトリを介してpipを使用することの利点/批判者は何ですか？

私が含めたリンクは

常に標準のDebian / NeuroDebianパッケージを常に使用する利点は、パッケージが互いに互換性があるように慎重にテストされることです。Debianパッケージは他のライブラリとの依存関係を記録するため、インストールの一部として必要なライブラリを常に取得できます。

アーチを使用します。これは、apt以外の他のパッケージ管理システムの場合ですか？

pipPythonモジュールをシステムモジュールとして、またはユーザーモジュールとしてシステムにインストールする際の最大の欠点は、ディストリビューションのパッケージ管理システムがそれらを認識しないことです。これは、それらを必要とする他のパッケージには使用せず、将来インストールする可能性がある（またはアップグレード後にこれらのモジュールのいずれかを使用し始める可能性がある）ことを意味します。その後pip、モジュールの配布管理バージョンと配布管理バージョンの両方が発生し、問題が発生する可能性があります（最近、この問題の別のインスタンスに遭遇しました）。オール・オア・ナッシングの命題であることまであなたの質問が終了するので：あなたの場合のみ使用することをpip Pythonモジュールの場合、Pythonモジュールを使用するものにはディストリビューションのパッケージマネージャーを使用できなくなります...

リンクしたページに記載されている一般的なアドバイスは非常に良いです。可能な限りディストリビューションのパッケージを使用しpip、パッケージ化されていないモジュールにのみ使用してください。ワイド。特にモジュール開発では、可能な限り仮想環境を使用してください。特にArchでは、古いモジュールが原因で問題が発生することはありません。それが問題になる可能性があるディストリビューションでも、仮想環境は非常に簡単に対処します。

ディストリビューションのライブラリおよびモジュールパッケージは、主にディストリビューション内の他のパッケージを使用するためにパッケージ化されていることを常に検討する価値があります。それらを持っていることは、それらのライブラリとモジュールを使用した開発にとって素晴らしい副作用ですが、それは主なユースケースではありません。

TL; DR

• 使用pipのもの（LIBS、フレームワーク、多分DEVツール）のための（+ virtualenvの）プロジェクト（あなたが開発していること）使用
• アプリケーションのためのパッケージマネージャを使用しますが、（エンドユーザーとして）を使用し

開発の依存関係

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つの一般的なカテゴリがあります。

1. OSパッケージシステムを使用してすべてのユーザーにインストールされるサポートプログラム。（これには、Pythonでプログラミングする人々が使用するツールやライブラリも含まれる場合があります。以下を参照してください。）これらの場合は、OSパッケージを使用し、pip必要に応じてシステムディレクトリにインストールします。
2. 特定のユーザーが自分の使用のためだけに、またスクリプト言語としてのPythonの「日常的な」使用の特定の側面のために、特定のユーザーによってインストールされるサポートプログラム。これらのために、彼女はpip --userおそらくpyenvまたはpythonzと同様のツールと戦術を使用します。
3. 特定のアプリケーションの開発と使用をサポートするもの。これらには、virtualenv（または同様のツール）を使用します。

ここの各レベルは、前のレベルからサポートを受けている場合もあります。たとえば、（2）のユーザーは、OSパッケージを介してインストールされたPythonインタープリターに依存している可能性があります。

これについてもう少し詳しく説明します。

システムプログラムとパッケージ

「実行する」だけのPythonで書かれたプログラムは簡単です。OSインストールツールを使用するだけで、必要なものをすべて取り込むことができます。これは、非Pythonプログラムと違いはありません。これは、あなたのマシンのユーザーが依存し始めるかもしれないPythonツール/ライブラリ（Pythonインタプリタ自体など！）をもたらす可能性があります。依存関係を理解し​​、理想的には、それらの依存関係を提供しないホストでそれを処理する代替手段を知っている限り、これは問題ではありません。

そのような依存関係の一般的で単純な例は、~/.local/bin/で始まる私の個人的なスクリプトの一部です#!/usr/bin/env python。これらは（Python 2で実行される限り）RH / CentOS 7およびほとんど（すべてではない）Ubuntuインストールで正常に動作します。基本的なDebianのインストール下またはWindows上ではありません。私の個人的な環境がOSパッケージに依存するという点で非常に嫌いなのですが（私は多くの異なるOSで働いています）、このようなことはかなり受け入れられると思います。システムPythonを持たず、システムPythonを取得できないまれなホストでのバックアップ計画は、以下に説明するようにユーザーシステムを使用することです。

システムpythonインタープリターを使用している人は通常、システムに依存していますpip3。これは、通常、システムの依存関係について線を引く場所です。virtualenv前方からすべて私は自分自身に対処します。（例えば、私の標準アクティブスクリプトが何に依存しているpip3か、pipパスにあるが、それ自身のコピーをダウンロードvirtualenvそれは作成の仮想環境をブートストラップします。

とはいえ、開発環境をもっと利用可能にすることが完全に合理的である状況はおそらくあるでしょう。Pythonのインターフェイスを複雑なパッケージ（DBMSなど）に入れて、そのシステムバージョンを使用したい場合があります。また、システムと対話するために使用する特定のPythonライブラリコードをシステムに選択させることをお勧めします。または、Pythonクラスの基本的な開発環境を備えた多くのホストを展開し、標準システムパッケージを使用して自動化するのが最も簡単であることがわかります。

ユーザーの「日々」のプログラムとパッケージ

ユーザーは、最初に仮想環境（例：virtualenvwrapper）を作成したい、またはコマンドラインからよく使用するものであるため、仮想環境にうまく適合しないPythonライブラリまたはプログラムを持っている可能性がありますPython以外の仕事をしています。これらのシステムバージョンをインストールする機能を持っている場合でも、（たとえば、ツールとその依存関係の最新バージョンを使用したいため）独自のインストールをより快適に感じるかもしれません。

一般的に、これpip --userは人々がこれに使用するものですが、Pythonインタープリター自体などの特定の依存関係は、それよりも少し多く必要です。pyenvとpythonzは~/.local/bin、デフォルトのインタープリターとしてインストールされるかどうかにかかわらず、個人的なインタープリターを構築するのに役立ちます。もちろん、devライブラリが利用可能な場合は、ソースからいつでも「手作業」でビルドできます。

ここにインストールされているものの最低限のセットを維持しようとしています：virtualenvwrapper（私は絶えず使用しているため）と、おそらく最新バージョンのpip。私は、多くのホストで使用される個人用スクリプトについて、標準ライブラリ外またはPython 3の依存関係を回避しようとしています。（これらの個人的なスクリプトの多くをPythonに移行するにつれて、どれだけ長く耐えられるかがわかります。）

個別のアプリケーション開発環境とランタイム環境

これは通常のvirtualenvのことです。開発では、ほとんどの場合、virtualenvを使用してシステムの依存関係を使用しないようにします。多くの場合、複数のPythonバージョンに対するテストには複数の環境を使用します。

これらの仮想環境は、ユーザー環境の汚染を避けたい多くの依存関係があるアプリケーションにも適しています。たとえば、私は通常Jupyterノートブックなどを実行するためのvirtualenvをセットアップします。