web-dev-qa-db-ja.com

requirements.txtとsetup.py

Pythonを使い始めました。 requirements.txtとsetup.pyをプロジェクトに追加しました。しかし、私はまだ両方のファイルの目的について混乱しています。 setup.pyは再配布可能なもの用に設計されており、requirements.txtは再配布不可能なもの用に設計されていることを読みました。しかし、これが正確かどうかはわかりません。

これらの2つのファイルは、実際にどのように使用されることを意図していますか？

pythonsetup.pyrequirements.txt
62
lucy

requirements.txt

これは、開発環境をセットアップするのに役立ちます。 pipなどのプログラムを使用すると、ファイルにリストされているすべてのパッケージを一気にインストールできます。その後、pythonスクリプトの開発を開始できます。他の人が開発に貢献したり、仮想環境を使用したりする場合に特に便利です。これがあなたの使い方です：

pip install -r < requirements.txt

setup.py

これにより、再配布可能なパッケージを作成できます。このスクリプトは、pip install -r < requirements.txtのように開発環境を準備するためではなく、エンドユーザーのシステムにパッケージをインストールするためのものです。 setup.pyの詳細については、 この回答 を参照してください。

プロジェクトの依存関係は両方のファイルにリストされています。

42
AndreasT

簡単な答えは、requirements.txtはパッケージ要件のみをリストするためのものです。一方、setup.pyはインストールスクリプトに似ています。 pythonコードのインストールを計画していない場合、通常はrequirements.txtのみが必要です。

ファイルsetup.pyは、パッケージの依存関係に加えて、パッケージ化（またはネイティブモジュールの場合はコンパイル（Cで記述））する必要があるファイルとモジュールのセット、および追加するメタデータを記述しますpythonパッケージリスト（パッケージ名、パッケージバージョン、パッケージの説明、作成者など）。

両方のファイルに依存関係がリストされているため、これにより少し重複する可能性があります。詳細については以下をお読みください。

requirements.txt

このファイルには、pythonパッケージ要件がリストされています。 pythonプロジェクトのパッケージdependenciesをリストするプレーンテキストファイル（オプションでコメント付き）です（1行に1つ）。 pythonパッケージのインストール方法はで説明されていません。通常、要件ファイルはpip install -r requirements.txtで消費します。

テキストファイルのファイル名は任意ですが、慣例により多くの場合requirements.txtです。他のpythonパッケージのソースコードリポジトリを調べると、dev-dependencies.txtやdependencies-dev.txtなど、他の名前に出くわすことがあります。これらはdependencies.txtと同じ目的を果たしますが、一般に、特定のパッケージの開発者にとって関心のある追加の依存関係、つまりリリース前にソースコード（pytest、pylintなど）をテストするための依存関係をリストします。通常、パッケージのユーザーは、パッケージを実行するために開発者の依存関係のセット全体を必要としません。

Multiplerequirements-X.txtバリアントが存在する場合、通常、1つはランタイム依存関係をリストし、もう1つはビルド時またはテスト依存関係をリストします。一部のプロジェクトでは、要件ファイルもカスケードされます。つまり、ある要件ファイルに別のファイルが含まれる場合（ example ）。そうすることで、繰り返しを減らすことができます。

setup.py

これは、pythonパッケージ（名前、含まれるファイル、パッケージメタデータ、およびインストール）を定義するためにsetuptoolsモジュールを使用するpythonスクリプトです。 requirements.txtと同様に、パッケージのランタイム依存関係もリストします。 Setuptoolsはpythonパッケージをビルドおよびインストールするためのデファクトな方法ですが、pipのような新しい「メタパッケージマネージャー」の開発に時間がかかっている欠点があります。 setuptoolsの欠点の例は、同じパッケージの複数のバージョンをインストールできないこと、およびアンインストールコマンドがないことです。

pythonユーザーがpip install ./pkgdir_my_module（またはpip install my-module）を実行すると、pipは指定されたディレクトリ（またはモジュール）でsetup.pyを実行します。同様に、setup.pyを持つモジュールはpip-にインストールできます。同じフォルダーからpip install .を実行します。

本当に両方必要ですか？

短い答えはノーですが、両方を持っているのはいいことです。これらは異なる目的を達成しますが、両方を使用して依存関係をリストできます。

requirements.txtとsetup.pyの間の依存関係のリストの重複を避けるために考慮することができる1つのトリックがあります。パッケージに対して完全に機能するsetup.pyをすでに作成しており、依存関係がほとんど外部である場合は、以下のみを備えた単純なrequirements.txtを使用することを検討できます。

 # requirements.txt
 #
 # installs dependencies from ./setup.py, and the package itself,
 # in editable mode
 -e .

 # (the -e above is optional). you could also just install the package
 # normally with just the line below (after uncommenting)
 # .

-eは、特定のパッケージをeditableモードでインストールする特別なpip installオプションです。このファイルに対してpip -r requirements.txtが実行されると、pipは./setup.pyのリストを介して依存関係をインストールします。編集可能なオプションは、インストールディレクトリにシンボリックリンクを配置します（Eggまたはアーカイブされたコピーの代わりに）。開発者は、再インストールせずにリポジトリからコードを編集できます。

パッケージリポジトリに両方のファイルがある場合、「setuptools extras」と呼ばれるものを利用することもできます。 setup.pyでカスタムカテゴリの下にオプションパッケージを定義し、pipを使用してそのカテゴリのみからそれらのパッケージをインストールできます。

# setup.py
from setuptools import setup
setup(
   name="FOO"
   ...
   extras_require = {
       'dev': ['pylint'],
       'build': ['requests']
   }
   ...
)

そして、要件ファイルで：

# install packages in the [build] category, from setup.py
# (path/to/mypkg is the directory where setup.py is)
-e path/to/mypkg[build]

これにより、すべての依存関係リストがsetup.py内に保持されます。

注：通常、プログラムvirtualenvで作成されたものなど、サンドボックスからpipとsetup.pyを実行します。これにより、プロジェクトの開発環境のコンテキスト外にpythonパッケージをインストールすることを回避できます。

32
init_js

完全を期すために、3つの異なる角度でそれを見る方法を以下に示します。

  1. それらの設計目的は異なります

これは、 公式ドキュメント （強調鉱山）から引用された正確な説明です：

（setup.pyの）install_requiresが依存関係を定義するのに対し単一プロジェクトの場合、要件の定義には要件ファイルがよく使用されます完全なPython環境の場合 。

Install_requires要件は最小限ですが、要件ファイルには多くの場合、完全な環境の反復可能なインストールを実現するために、固定バージョンの完全なリストが含まれています。

しかし、理解するのはまだ容易ではないかもしれないので、次のセクションでは、2つのアプローチが異なる方法で使用されることになっている2つの事実の例を示します。

  1. したがって、実際の使用法は（想定される）異なる

    • プロジェクトfooがスタンドアロンライブラリとしてリリースされる場合（つまり、他の人がおそらくimport fooを行うことになる）、あなた（およびあなたのダウンストリームユーザー）は依存関係の柔軟な宣言が必要になります。あなたのライブラリがあなたの依存関係の正確なバージョンがどうあるべきかについて「ピッキー」ではない（そしてそうではない）したがって、通常、setup.pyには次のような行が含まれます。

      install_requires=[
    'A>=1,<2',
    'B>=2'
]

    • アプリケーションの正確な現在の環境を何らかの方法で「文書化」または「固定」したい場合は、bar、つまり、あなたまたはユーザーはアプリケーションをbarそのまま使用したい、つまりpython bar.py、常に同じように動作するように環境を凍結することができます。そのような場合、要件ファイルは次のようになります。

      A==1.2.3
B==2.3.4
# It could even contain some dependencies NOT strickly required by your library
pylint==3.4.5

  2. 実際には、どれを使用しますか？

    • barで使用されるアプリケーションを開発している場合、python bar.pyで使用されますが、たとえそれが「ただの楽しみのためのスクリプト」であっても、来週（たまたまクリスマス）ギフトとして新しいコンピューターを受け取るので、正確な環境を再度セットアップする必要があります。

    • import fooで使用されるライブラリfooを開発している場合、setup.pyを準備する必要があります。期間。ただし、requirements.txtを同時に提供することもできます。

      （a）A==1.2.3スタイルのいずれか（上記の＃2で説明）。

      （b）または魔法のシングル.を含む

      .

      これは、「setup.pyに基づいて要件をインストールする」とほぼ同じですが、重複はありません。個人的には、この最後のアプローチは種類を曖昧にし、混乱を助長し、実際に価値を付加するものではないと考えていますが、それでもPythonパッケージメンテナーDonaldが言及したアプローチから派生したトリックです 彼のブログ投稿 。

7
RayLuo