Pythonモジュールのインストール（レガシーバージョン）
- 著者
- グレッグウォード
ノート
このドキュメントは、 https://setuptools.readthedocs.io/en/latest/setuptools.htmlのsetuptoolsドキュメントが、現在ここに含まれているすべての関連情報を個別にカバーするまでのみ保持されます。
ノート
このガイドでは、このバージョンのPythonの一部として提供される拡張機能を構築および配布するための基本的なツールについてのみ説明します。 サードパーティのツールは、より使いやすく、より安全な代替手段を提供します。 詳細については、PythonPackagingユーザーガイドのクイック推奨セクションを参照してください。
序章
Python 2.0では、distutils APIが最初に標準ライブラリに追加されました。 これにより、LinuxディストリビューションのメンテナはPythonプロジェクトをLinuxディストリビューションパッケージに変換する標準的な方法を提供し、システム管理者はそれらをターゲットシステムに直接インストールする標準的な方法を提供しました。
Python 2.0がリリースされてから何年もの間、ビルドシステムとパッケージインストーラーを言語ランタイムリリースサイクルに緊密に結合することは問題があることが判明しました。プロジェクトではpipパッケージインストーラーとdistutilsを直接使用するのではなく、setuptoolsビルドシステム。
詳細については、 Pythonモジュールのインストールおよび Pythonモジュールの配布を参照してください。
このレガシードキュメントは、setuptoolsドキュメントが必要なすべてをカバーしていると確信するまでのみ保持されます。
Distutilsベースのソース配布
モジュールソースディストリビューションをダウンロードすると、標準的な方法でパッケージ化および配布されたかどうかをすぐに確認できます。 Distutilsを使用します。 まず、ディストリビューションの名前とバージョン番号は、ダウンロードしたアーカイブの名前で目立つように表示されます。 foo-1.0.tar.gzまたはwidget-0.9.7.zip。 次に、アーカイブは同じ名前のディレクトリfoo-1.0またはwidget-0.9.7に解凍されます。 さらに、ディストリビューションには、セットアップスクリプトsetup.pyと、README.txtまたは場合によってはREADMEという名前のファイルが含まれます。これは、モジュールディストリビューションの構築とインストールが簡単なことであることを説明する必要があります。端末から1つのコマンドを実行する方法：
python setup.py install
Windowsの場合、このコマンドはコマンドプロンプトウィンドウ（）から実行する必要があります。
setup.py install
これらすべてが当てはまる場合は、ダウンロードしたモジュールをビルドしてインストールする方法をすでに知っています。上記のコマンドを実行します。 非標準的な方法でインストールしたり、ビルドプロセスをカスタマイズしたりする必要がない限り、このマニュアルは実際には必要ありません。 むしろ、上記のコマンドは、このマニュアルから抜け出すために必要なすべてです。
標準のビルドとインストール
セクション Distutilsベースのソースディストリビューションで説明されているように、Distutilsを使用したモジュールディストリビューションの構築とインストールは、通常、ターミナルから実行する1つの簡単なコマンドです。
python setup.py install
プラットフォームのバリエーション
常に配布ルートディレクトリからセットアップコマンドを実行する必要があります。 モジュールソースディストリビューションが解凍する最上位のサブディレクトリ。 たとえば、モジュールソースディストリビューションfoo-1.0.tar.gzをUnixシステムにダウンロードしたばかりの場合、通常は次のようにします。
gunzip -c foo-1.0.tar.gz | tar xf - # unpacks into directory foo-1.0
cd foo-1.0
python setup.py install
Windowsでは、おそらくfoo-1.0.zipをダウンロードします。 アーカイブファイルをC:\Tempにダウンロードした場合、C:\Temp\foo-1.0に解凍されます。 グラフィカルユーザーインターフェイス（WinZipなど）を備えたアーカイブマニピュレーターまたはコマンドラインツール（ unzip または pkunzip など）を使用して、アーカイブを解凍できます。 次に、コマンドプロンプトウィンドウを開いて、次のコマンドを実行します。
cd c:\Temp\foo-1.0
python setup.py install
ジョブを分割する
setup.py installを実行すると、すべてのモジュールが1回の実行でビルドおよびインストールされます。 段階的に作業する場合（特にビルドプロセスをカスタマイズする場合、または問題が発生する場合に便利です）、セットアップスクリプトを使用して一度に1つのことを実行できます。 これは、ビルドとインストールが異なるユーザーによって行われる場合に特に役立ちます。たとえば、モジュールディストリビューションをビルドして、インストールのためにシステム管理者に渡す（またはスーパーユーザー権限で自分で行う）場合があります。
たとえば、セットアップスクリプトを2回呼び出すことで、すべてを1つのステップでビルドし、次にすべてを2番目のステップでインストールできます。
python setup.py build
python setup.py install
これを行うと、 install コマンドを実行すると最初に build コマンドが実行されることに気付くでしょう。この場合、このコマンドは何の関係もないことにすぐに気付きます。 buildディレクトリは最新です。
ネットからダウンロードしたモジュールをインストールするだけの場合は、この機能を頻繁に分解する必要はないかもしれませんが、より高度なタスクには非常に便利です。 独自のPythonモジュールと拡張機能を配布する場合は、多数の個別のDistutilsコマンドを独自に実行します。
建物のしくみ
上記のように、 build コマンドは、インストールするファイルを buildディレクトリに配置する役割を果たします。 デフォルトでは、これはディストリビューションルートの下のbuildです。 速度に過度に関心がある場合、またはソースツリーを元の状態に保ちたい場合は、--build-baseオプションを使用してビルドディレクトリを変更できます。 例えば：
python setup.py build --build-base=/path/to/pybuild/foo-1.0
（または、システムまたは個人のDistutils構成ファイルのディレクティブを使用してこれを永続的に行うことができます。セクション Distutils構成ファイルを参照してください。）通常、これは必要ありません。
ビルドツリーのデフォルトのレイアウトは次のとおりです。
--- build/ --- lib/
or
--- build/ --- lib.<plat>/
temp.<plat>/
ここで、<plat>は、現在のOS /ハードウェアプラットフォームとPythonバージョンの簡単な説明に展開されます。 libディレクトリのみを持つ最初の形式は、「純粋なモジュール配布」、つまり純粋なPythonモジュールのみを含むモジュール配布に使用されます。 モジュールディストリビューションに拡張機能（C / C ++で記述されたモジュール）が含まれている場合は、2つの<plat>ディレクトリを持つ2番目の形式が使用されます。 その場合、temp.platディレクトリには、コンパイル/リンクプロセスによって生成された、実際にはインストールされない一時ファイルが保持されます。 いずれの場合も、lib（またはlib.plat）ディレクトリには、インストールされるすべてのPythonモジュール（純粋なPythonおよび拡張機能）が含まれています。
将来的には、Pythonスクリプト、ドキュメント、バイナリ実行可能ファイルなど、Pythonモジュールとアプリケーションのインストールジョブを処理するために必要なものを処理するために、さらに多くのディレクトリが追加される予定です。
インストールの仕組み
build コマンドの実行後（明示的に実行するか、 install コマンドで実行するかに関係なく）、 install コマンドの作業は比較的簡単です。 build/lib（またはbuild/lib.plat）の下にあるすべてのものを、選択したインストールディレクトリにコピーするだけです。
インストールディレクトリを選択しない場合、つまりsetup.py installを実行するだけの場合、 install コマンドはサードパーティのPythonモジュールの標準の場所にインストールされます。 この場所は、プラットフォームやPython自体の構築/インストール方法によって異なります。 Unix（およびUnixベースのmacOS）では、インストールされているモジュールディストリビューションが純粋なPythonであるか、拡張機能（「非純粋」）が含まれているかによっても異なります。
| プラットホーム | 標準の設置場所 | デフォルト値 | ノート |
|---|---|---|---|
| Unix（純粋） | prefix/lib/pythonX.Y/site-packages
|
/usr/local/lib/pythonX.Y/site-packages
|
(1) |
| Unix（非純粋） | exec-prefix/lib/pythonX.Y/site-packages
|
/usr/local/lib/pythonX.Y/site-packages
|
(1) |
| ウィンドウズ | prefix\Lib\site-packages
|
C:\PythonXY\Lib\site-packages
|
(2) |
ノート：
- ほとんどのLinuxディストリビューションには、システムの標準部分としてPythonが含まれているため、Linuxでは
prefixとexec-prefixは通常両方とも/usrです。 Linux（またはUnixライクなシステム）でPythonを自分でビルドする場合、デフォルトのprefixとexec-prefixは/usr/localです。 - Windowsのデフォルトのインストールディレクトリは、Python 1.6a1、1.5.2以前では
C:\Program Files\Pythonでした。
prefixおよびexec-prefixは、Pythonがインストールされているディレクトリと、実行時にライブラリが見つかる場所を表します。 これらはWindowsでは常に同じであり、UnixとmacOSでも同じであることがよくあります。 Pythonをインタラクティブモードで実行し、いくつかの簡単なコマンドを入力することで、Pythonインストールがprefixおよびexec-prefixに何を使用するかを確認できます。 Unixでは、シェルプロンプトでpythonと入力するだけです。 Windowsでは、を選択します。 インタプリタが起動したら、プロンプトでPythonコードを入力します。 たとえば、私のLinuxシステムでは、以下に示す3つのPythonステートメントを入力し、次のように出力を取得して、prefixとexec-prefixを見つけます。
Python 2.4 (#26, Aug 7 2004, 17:19:02)
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.prefix
'/usr'
>>> sys.exec_prefix
'/usr'このドキュメントでは、他のいくつかのプレースホルダーが使用されています。X.Yは、Pythonのバージョンを表します（例：3.2）。 abiflagsは、 sys.abiflags の値、またはABIフラグを定義しないプラットフォームの場合は空の文字列に置き換えられます。 distnameは、インストールされているモジュールディストリビューションの名前に置き換えられます。 パスでは、ドットと大文字化が重要です。 たとえば、UNIXでpython3.2を使用する値は、通常、WindowsではPython32を使用します。
モジュールを標準の場所にインストールしたくない場合、またはそこに書き込む権限がない場合は、セクション代替インストールで代替インストールについて読む必要があります。 インストールディレクトリをさらに大幅にカスタマイズする場合は、カスタムインストールのセクションカスタムインストールを参照してください。
代替インストール
多くの場合、サードパーティのPythonモジュールの標準的な場所以外の場所にモジュールをインストールすることが必要または望ましいです。 たとえば、Unixシステムでは、標準のサードパーティモジュールディレクトリに書き込む権限がない場合があります。 または、モジュールをローカルPythonインストールの標準部分にする前に、モジュールを試してみることをお勧めします。 これは、すでに存在するディストリビューションをアップグレードする場合に特に当てはまります。実際にアップグレードする前に、既存のスクリプトベースが新しいバージョンで引き続き機能することを確認する必要があります。
Distutils install コマンドは、モジュール配布を別の場所に簡単かつ簡単にインストールできるように設計されています。 基本的な考え方は、インストール用のベースディレクトリを指定し、 install コマンドは、ファイルをインストールするこのベースディレクトリの下にあるディレクトリのセット（インストールスキームと呼ばれる）を選択することです。 。 詳細はプラットフォームによって異なるため、次のセクションのいずれかに該当するものをお読みください。
さまざまな代替インストールスキームは相互に排他的であることに注意してください。--user、--home、または--prefixと--exec-prefix、または--install-baseを渡すことができます。 ]と--install-platbaseですが、これらのグループから混合することはできません。
代替インストール：ユーザースキーム
このスキームは、グローバルsite-packagesディレクトリへの書き込み権限がないユーザー、またはディレクトリにインストールしたくないユーザーにとって最も便利なソリューションとなるように設計されています。 簡単なオプションで有効になります：
python setup.py install --user
ファイルは site.USER_BASE のサブディレクトリにインストールされます（以降、userbaseと表記します）。 このスキームは、純粋なPythonモジュールと拡張モジュールを同じ場所（ site.USER_SITE とも呼ばれます）にインストールします。 macOSを含むUNIXの値は次のとおりです。
| ファイルの種類 | インストールディレクトリ |
|---|---|
| モジュール | userbase/lib/pythonX.Y/site-packages
|
| スクリプト | userbase/bin
|
| データ | userbase
|
| Cヘッダー | userbase/include/pythonX.Yabiflags/distname
|
そして、これがWindowsで使用される値です。
| ファイルの種類 | インストールディレクトリ |
|---|---|
| モジュール | userbase\PythonXY\site-packages
|
| スクリプト | userbase\PythonXY\Scripts
|
| データ | userbase
|
| Cヘッダー | userbase\PythonXY\Include{distname}
|
以下で説明する他のスキームと比較してこのスキームを使用する利点は、ユーザーsite-packagesディレクトリが通常の状態で常に sys.path に含まれることです（詳細については、 site を参照してください）。 、これは、setup.pyスクリプトを実行してインストールを完了した後に実行する追加の手順がないことを意味します。
build_ext コマンドには--userオプションもあり、ヘッダーファイルのコンパイラ検索パスにuserbase/includeを追加し、ライブラリのコンパイラ検索パスにuserbase/libを追加します。共有Cライブラリのランタイム検索パス（rpath）も同様です。
代替インストール：ホームスキーム
「ホームスキーム」の背後にある考え方は、Pythonモジュールの個人的な隠し場所を構築して維持することです。 このスキームの名前は、Unixユーザーがホームディレクトリを/usr/または/usr/local/のようなレイアウトにすることは珍しいことではないため、Unixの「ホーム」ディレクトリの概念に由来しています。 このスキームは、インストール先のオペレーティングシステムに関係なく、誰でも使用できます。
新しいモジュールディストリビューションのインストールは、次のように簡単です。
python setup.py install --home=<dir>
--homeオプション用に任意のディレクトリを指定できます。 Unixでは、怠惰なタイピストはチルダ（~）を入力するだけです。 install コマンドは、これをホームディレクトリに展開します。
python setup.py install --home=~
Pythonにこのスキームでインストールされたディストリビューションを検索させるには、 Pythonの検索パスを変更するか、sitecustomize（サイトを参照）を編集してサイトを呼び出す必要があります。 addsitedir（）または sys.path を編集します。
--homeオプションは、インストールベースディレクトリを定義します。 ファイルは、インストールベースの下の次のディレクトリに次のようにインストールされます。
| ファイルの種類 | インストールディレクトリ |
|---|---|
| モジュール | home/lib/python
|
| スクリプト | home/bin
|
| データ | home
|
| Cヘッダー | home/include/python/distname
|
（Windowsを使用している場合は、スラッシュを円記号に精神的に置き換えてください。）
代替インストール：Unix（プレフィックススキーム）
「プレフィックススキーム」は、1つのPythonインストールを使用してビルド/インストールを実行する（つまり、セットアップスクリプトを実行する）が、モジュールを別のPythonインストールのサードパーティモジュールディレクトリ（または別のPythonインストールのように見えます）。 これがささいなことのように聞こえるなら、それはそうです—それがユーザーとホームスキームが前に来る理由です。 ただし、プレフィックススキームが役立つ既知のケースが少なくとも2つあります。
まず、多くのLinuxディストリビューションがPythonを従来の/usr/localではなく、/usrに配置していることを考慮してください。 これらの場合、Pythonはローカルアドオンではなく「システム」の一部であるため、これは完全に適切です。 ただし、Pythonモジュールをソースからインストールする場合は、/usr/lib/python2.Xではなく/usr/local/lib/python2.Xにインストールすることをお勧めします。 これはで行うことができます
/usr/bin/python setup.py install --prefix=/usr/local
別の可能性は、リモートディレクトリへの書き込みに使用される名前がそれを読み取るために使用される名前と異なるネットワークファイルシステムです。たとえば、/usr/local/bin/pythonとしてアクセスされるPythonインタープリターは、/usr/local/lib/python2.X内のモジュールを検索する可能性があります。 ]ですが、これらのモジュールは、たとえば/mnt/@server/export/lib/python2.Xにインストールする必要があります。 これはで行うことができます
/usr/local/bin/python setup.py install --prefix=/mnt/@server/export
いずれの場合も、--prefixオプションはインストールベースを定義し、--exec-prefixオプションはプラットフォーム固有のインストールベースを定義します。これはプラットフォーム固有のファイルに使用されます。 （現在、これは純粋でないモジュール配布を意味しますが、Cライブラリ、バイナリ実行可能ファイルなどに拡張できます。）--exec-prefixが指定されていない場合、デフォルトで--prefixになります。 ファイルは次のようにインストールされます。
| ファイルの種類 | インストールディレクトリ |
|---|---|
| Pythonモジュール | prefix/lib/pythonX.Y/site-packages
|
| 拡張モジュール | exec-prefix/lib/pythonX.Y/site-packages
|
| スクリプト | prefix/bin
|
| データ | prefix
|
| Cヘッダー | prefix/include/pythonX.Yabiflags/distname
|
--prefixまたは--exec-prefixが実際に代替Pythonインストールを指している必要はありません。 上記のディレクトリがまだ存在しない場合は、インストール時に作成されます。
ちなみに、プレフィックススキームが重要である本当の理由は、標準のUnixインストールがプレフィックススキームを使用するということですが、--prefixと--exec-prefixはPython自体によってsys.prefixと[ X205X] 。 したがって、プレフィックススキームを使用することはないと思うかもしれませんが、他のオプションなしでpython setup.py installを実行するたびに、それを使用しています。
代替Pythonインストールに拡張機能をインストールしても、それらの拡張機能の構築方法には影響しないことに注意してください。特に、セットアップスクリプトの実行に使用されるPythonインタープリターとともにインストールされたPythonヘッダーファイル（Python.hなど）が使用されます。拡張機能のコンパイルで。 この方法でインストールされた拡張機能を実行するために使用されるインタプリタが、それらを構築するために使用されるインタプリタと互換性があることを確認するのはあなたの責任です。 これを行う最良の方法は、2つのインタープリターが同じバージョンのPython（おそらく異なるビルド、または同じビルドのコピー）であることを確認することです。 （もちろん、--prefixと--exec-prefixが代替のPythonインストールを指していない場合、これは重要ではありません。）
代替インストール：Windows（プレフィックススキーム）
Windowsにはユーザーのホームディレクトリの概念がなく、Windowsでの標準のPythonインストールはUnixよりも簡単であるため、--prefixオプションは、従来、Windowsの別々の場所に追加のパッケージをインストールするために使用されてきました。
python setup.py install --prefix="\Temp\Python"
現在のドライブの\Temp\Pythonディレクトリにモジュールをインストールします。
インストールベースは、--prefixオプションで定義されます。 --exec-prefixオプションはWindowsではサポートされていません。つまり、純粋なPythonモジュールと拡張モジュールが同じ場所にインストールされます。 ファイルは次のようにインストールされます。
| ファイルの種類 | インストールディレクトリ |
|---|---|
| モジュール | prefix\Lib\site-packages
|
| スクリプト | prefix\Scripts
|
| データ | prefix
|
| Cヘッダー | prefix\Include{distname}
|
カスタムインストール
セクション代替インストールで説明されている代替インストールスキームでは、意図したとおりに動作しない場合があります。 すべてを同じベースディレクトリに保持しながら、1つまたは2つのディレクトリだけを微調整することも、インストールスキームを完全に再定義することもできます。 いずれの場合も、カスタムインストールスキームを作成しています。
カスタムインストールスキームを作成するには、代替スキームの1つから開始し、次のオプションを使用して、さまざまなタイプのファイルに使用されるインストールディレクトリの一部を上書きします。
| ファイルの種類 | オーバーライドオプション |
|---|---|
| Pythonモジュール | --install-purelib
|
| 拡張モジュール | --install-platlib
|
| すべてのモジュール | --install-lib
|
| スクリプト | --install-scripts
|
| データ | --install-data
|
| Cヘッダー | --install-headers
|
これらのオーバーライドオプションは、相対、絶対、またはインストールベースディレクトリの1つに関して明示的に定義できます。 （2つのインストールベースディレクトリがあり、通常は同じです。これらは、Unixの「プレフィックススキーム」を使用し、異なる--prefixおよび--exec-prefixオプションを提供する場合にのみ異なります。 [を使用するX196X]は、--install-purelibおよび--install-platlibに対して計算または指定された値をオーバーライドし、Pythonと拡張モジュールの間に違いがないスキームに推奨されます。）
たとえば、Unixのホームディレクトリにモジュールディストリビューションをインストールしているが、スクリプトを~/binではなく~/scriptsに配置したいとします。 ご想像のとおり、このディレクトリは--install-scriptsオプションで上書きできます。 この場合、相対パスを指定するのが最も理にかなっています。相対パスは、インストールベースディレクトリ（この場合はホームディレクトリ）を基準にして解釈されます。
python setup.py install --home=~ --install-scripts=scripts
別のUnixの例：Pythonインストールが/usr/local/pythonのプレフィックスでビルドおよびインストールされたとすると、標準のインストールではスクリプトは/usr/local/python/binになります。 代わりに/usr/local/binに配置する場合は、--install-scriptsオプションに次の絶対ディレクトリを指定します。
python setup.py install --install-scripts=/usr/local/bin
（これは、「プレフィックススキーム」を使用してインストールを実行します。プレフィックスは、Pythonインタープリターがインストールされたもの（この場合は/usr/local/python）です。）
WindowsでPythonを保守している場合は、サードパーティのモジュールをprefix自体ではなく、prefixのサブディレクトリに配置することをお勧めします。 これは、スクリプトのインストールディレクトリをカスタマイズするのとほぼ同じくらい簡単です。心配するモジュールには、Pythonと拡張モジュールの2種類があり、どちらも1つのオプションで簡単に制御できることを覚えておく必要があります。
python setup.py install --install-lib=Site
指定されたインストールディレクトリは、prefixを基準にしています。 もちろん、.pthファイルをサイトディレクトリに配置するなどして、このディレクトリがPythonのモジュール検索パスにあることも確認する必要があります（ site を参照）。 Pythonの検索パスを変更する方法については、セクション Pythonの検索パスの変更を参照してください。
インストールスキーム全体を定義する場合は、すべてのインストールディレクトリオプションを指定するだけです。 これを行うための推奨される方法は、相対パスを指定することです。 たとえば、ホームディレクトリのpythonの下にすべてのPythonモジュール関連ファイルを保持し、ホームディレクトリを使用するプラットフォームごとに個別のディレクトリが必要な場合は、次のインストールスキームを定義できます。 ：
python setup.py install --home=~ \
--install-purelib=python/lib \
--install-platlib=python/lib.$PLAT \
--install-scripts=python/scripts
--install-data=python/data
または、同等に、
python setup.py install --home=~/python \
--install-purelib=lib \
--install-platlib='lib.$PLAT' \
--install-scripts=scripts
--install-data=data
$PLATは（必然的に）環境変数ではありません。構成ファイルを解析するときと同じように、コマンドラインオプションを解析するときにDistutilsによって展開されます。
明らかに、新しいモジュールディストリビューションをインストールするたびにインストールスキーム全体を指定するのは非常に面倒です。 したがって、これらのオプションをDistutils構成ファイルに入れることができます（セクション Distutils構成ファイルを参照）。
[install]
install-base=$HOME
install-purelib=python/lib
install-platlib=python/lib.$PLAT
install-scripts=python/scripts
install-data=python/dataまたは、同等に、
[install]
install-base=$HOME/python
install-purelib=lib
install-platlib=lib.$PLAT
install-scripts=scripts
install-data=dataセットアップスクリプトの実行時に別のインストールベースディレクトリを指定した場合、これら2つは同等ではないことに注意してください。 例えば、
python setup.py install --install-base=/tmp
最初のケースでは/tmp/python/libに、2番目のケースでは/tmp/libに純粋なモジュールをインストールします。 （2番目のケースでは、おそらく/tmp/pythonのインストールベースを提供する必要があります。）
サンプル構成ファイルの入力で$HOMEと$PLATが使用されていることに気付いたと思います。 これらはDistutils構成変数であり、環境変数と非常によく似ています。 実際、このような概念を持つプラットフォームの構成ファイルで環境変数を使用できますが、Distutilsは、$PLATなど、環境にない可能性のあるいくつかの追加変数を追加で定義します。 （もちろん、Mac OS 9などの環境変数を持たないシステムでは、Distutilsによって提供される構成変数のみを使用できます。）詳細については、セクション Distutils構成ファイルを参照してください。 。
ノート
仮想環境がアクティブ化されると、インストールパスを変更するオプションは、仮想環境の外部にプロジェクトを誤ってインストールすることを防ぐために、すべてのdistutils構成ファイルから無視されます。
Pythonの検索パスの変更
Pythonインタープリターが import ステートメントを実行すると、検索パスに沿ってPythonコードと拡張モジュールの両方が検索されます。 パスのデフォルト値は、インタープリターのビルド時にPythonバイナリに構成されます。 sys モジュールをインポートし、sys.pathの値を出力することで、パスを判別できます。
$ python
Python 2.2 (#11, Oct 3 2002, 13:31:27)
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', '/usr/local/lib/python2.3', '/usr/local/lib/python2.3/plat-linux2',
'/usr/local/lib/python2.3/lib-tk', '/usr/local/lib/python2.3/lib-dynload',
'/usr/local/lib/python2.3/site-packages']
>>>
sys.pathのnull文字列は、現在の作業ディレクトリを表します。
ローカルにインストールされたパッケージに期待される規則は、それらを…/site-packages/ディレクトリに配置することですが、Pythonモジュールを任意のディレクトリにインストールすることもできます。 たとえば、サイトには、Webサーバーに関連するすべてのソフトウェアを/wwwの下に保持するという規則がある場合があります。 アドオンPythonモジュールは/www/pythonに属している可能性があり、それらをインポートするには、このディレクトリをsys.pathに追加する必要があります。 ディレクトリを追加するには、いくつかの異なる方法があります。
最も便利な方法は、パス構成ファイルを、Pythonのパス上にあるディレクトリ、通常は.../site-packages/ディレクトリに追加することです。 パス構成ファイルの拡張子は.pthであり、各行にはsys.pathに追加される単一のパスが含まれている必要があります。 （新しいパスがsys.pathに追加されるため、追加されたディレクトリ内のモジュールは標準モジュールを上書きしません。 つまり、このメカニズムを使用して、標準モジュールの固定バージョンをインストールすることはできません。）
パスは絶対パスでも相対パスでもかまいません。その場合、パスは.pthファイルを含むディレクトリからの相対パスです。 詳細については、 site モジュールのドキュメントを参照してください。
少し便利ではない方法は、Pythonの標準ライブラリのsite.pyファイルを編集し、sys.pathを変更することです。 site.pyは、Pythonインタープリターの実行時に自動的にインポートされます。ただし、この動作を抑制するために -S スイッチが指定されている場合を除きます。 したがって、site.pyを編集して、それに2行を追加するだけです。
import sys
sys.path.append('/www/python/')ただし、同じメジャーバージョンのPythonを再インストールすると（たとえば、2.2から2.2.2にアップグレードする場合）、site.pyはストックバージョンで上書きされます。 インストールを行う前に、それが変更されたことを覚えて、コピーを保存する必要があります。
sys.pathを変更できる2つの環境変数があります。 PYTHONHOME は、Pythonインストールのプレフィックスの代替値を設定します。 たとえば、 PYTHONHOME が/www/pythonに設定されている場合、検索パスは[, '/www/python/lib/pythonX.Y/', '/www/python/lib/pythonX.Y/plat-linux2', ...]に設定されます。
PYTHONPATH 変数は、sys.pathの先頭に追加されるパスのリストに設定できます。 たとえば、 PYTHONPATH が/www/python:/opt/pyに設定されている場合、検索パスは['/www/python', '/opt/py']で始まります。 （sys.pathに追加するには、ディレクトリが存在する必要があることに注意してください。 site モジュールは、存在しないパスを削除します。）
最後に、sys.pathは単なる通常のPythonリストであるため、どのPythonアプリケーションでもエントリを追加または削除することでリストを変更できます。
Distutils構成ファイル
上記のように、Distutils構成ファイルを使用して、Distutilsオプションの個人設定またはサイト設定を記録できます。 つまり、任意のコマンドのオプションは、2つまたは3つの（プラットフォームに応じて）構成ファイルのいずれかに保存できます。これらの構成ファイルは、コマンドラインが解析される前に参照されます。 これは、構成ファイルがデフォルト値をオーバーライドし、コマンドラインが構成ファイルをオーバーライドすることを意味します。 さらに、複数の構成ファイルが適用される場合、「前の」ファイルの値は「後の」ファイルによって上書きされます。
構成ファイルの場所と名前
構成ファイルの名前と場所は、プラットフォームによってわずかに異なります。 UnixおよびmacOSでは、3つの構成ファイル（処理される順序）は次のとおりです。
| ファイルの種類 | 場所とファイル名 | ノート |
|---|---|---|
| システム | prefix/lib/pythonver/distutils/distutils.cfg
|
(1) |
| 個人的 | $HOME/.pydistutils.cfg
|
(2) |
| ローカル | setup.cfg
|
(3) |
また、Windowsでは、構成ファイルは次のとおりです。
| ファイルの種類 | 場所とファイル名 | ノート |
|---|---|---|
| システム | prefix\Lib\distutils\distutils.cfg
|
(4) |
| 個人的 | %HOME%\pydistutils.cfg
|
(5) |
| ローカル | setup.cfg
|
(3) |
すべてのプラットフォームで、 –no-user-cfg オプションを渡すことにより、「個人用」ファイルを一時的に無効にすることができます。
ノート：
- 厳密に言えば、システム全体の構成ファイルは、Distutilsがインストールされているディレクトリにあります。 Python 1.6以降のUnixでは、これは次のようになります。 Python 1.5.2の場合、Distutilsは通常
prefix/lib/python1.5/site-packages/distutilsにインストールされるため、システム構成ファイルはPython1.5.2の下に配置する必要があります。 - Unixでは、
HOME環境変数が定義されていない場合、ユーザーのホームディレクトリは、標準の pwd モジュールのgetpwuid()関数で決定されます。 。 これは、Distutilsが使用する os.path.expanduser（）関数によって実行されます。 - つまり、現在のディレクトリ（通常はセットアップスクリプトの場所）にあります。
- （注（1）も参照してください。）Python 1.6以降では、Pythonのデフォルトの「インストールプレフィックス」は
C:\Pythonであるため、システム構成ファイルは通常C:\Python\Lib\distutils\distutils.cfgです。 Python 1.5.2では、デフォルトのプレフィックスはC:\Program Files\Pythonであり、Distutilsは標準ライブラリの一部ではなかったため、システム構成ファイルは、標準のPython1.5.2インストールではC:\Program Files\Python\distutils\distutils.cfgになります。ウィンドウズ。 - Windowsでは、
HOME環境変数が定義されていない場合、USERPROFILE、HOMEDRIVEおよび[ X122X]HOMEPATHが試されます。 これは、Distutilsが使用する os.path.expanduser（）関数によって実行されます。
設定ファイルの構文
Distutils構成ファイルはすべて同じ構文を持っています。 構成ファイルはセクションにグループ化されています。 Distutilsコマンドごとに1つのセクションがあり、さらにすべてのコマンドに影響するグローバルオプション用のglobalセクションがあります。 各セクションは、option=valueとして指定された行ごとに1つのオプションで構成されます。
たとえば、以下は、すべてのコマンドをデフォルトで静かに実行するように強制する完全な構成ファイルです。
[global]
verbose=0これがシステム構成ファイルとしてインストールされている場合、現在のシステム上のすべてのユーザーによるPythonモジュール配布のすべての処理に影響します。 個人用設定ファイルとして（それらをサポートするシステムに）インストールされている場合、それはあなたが処理するモジュール配布にのみ影響します。 また、特定のモジュールディストリビューションのsetup.cfgとして使用されている場合は、そのディストリビューションにのみ影響します。
デフォルトの「ビルドベース」ディレクトリを上書きして、 build * コマンドで常にすべてのファイルを次のように強制的に再構築することができます。
[build]
build-base=blib
force=1これはコマンドライン引数に対応します
python setup.py build --build-base=blib --force
ただし、コマンドラインに build コマンドを含めると、コマンドが実行されます。 設定ファイルに特定のコマンドを含めても、そのような意味はありません。 これは、コマンドが実行された場合に、構成ファイルのオプションが適用されることを意味するだけです。 （または、そこから値を取得する他のコマンドが実行される場合、それらは構成ファイルの値を使用します。）
--helpオプションを使用すると、コマンドのオプションの完全なリストを見つけることができます。例：
python setup.py build --help
コマンドなしで--helpを使用すると、グローバルオプションの完全なリストを見つけることができます。
python setup.py --help
「Pythonモジュールの配布」マニュアルの「リファレンス」セクションも参照してください。
拡張機能の構築：ヒントとコツ
可能な限り、Distutilsは、setup.pyスクリプトの実行に使用されるPythonインタープリターによって提供される構成情報を使用しようとします。 たとえば、Pythonのコンパイルに使用されたものと同じコンパイラフラグとリンカフラグが、拡張機能のコンパイルにも使用されます。 通常、これはうまく機能しますが、複雑な状況ではこれは不適切な場合があります。 このセクションでは、通常のDistutilsの動作をオーバーライドする方法について説明します。
コンパイラ/リンカーフラグの調整
CまたはC ++で記述されたPython拡張機能をコンパイルするには、特定のライブラリを使用したり、特別な種類のオブジェクトコードを生成したりするために、コンパイラとリンカのカスタムフラグを指定する必要がある場合があります。 これは、拡張機能がプラットフォームでテストされていない場合、またはPythonをクロスコンパイルしようとしている場合に特に当てはまります。
最も一般的なケースでは、拡張機能の作成者は、拡張機能のコンパイルが複雑になることを予測し、編集用のSetupファイルを提供している可能性があります。 これは、モジュール配布に多くの個別の拡張モジュールが含まれている場合、またはそれらが機能するために精巧なコンパイラフラグのセットを必要とする場合にのみ行われる可能性があります。
Setupファイルが存在する場合は、ビルドする拡張機能のリストを取得するために解析されます。 Setupの各行は、単一のモジュールを表しています。 線の構造は次のとおりです。
module ... [sourcefile ...] [cpparg ...] [library ...]
各フィールドを順番に調べてみましょう。
- module は、構築する拡張モジュールの名前であり、有効なPython識別子である必要があります。 モジュールの名前を変更するためにこれを変更することはできません（ソースコードの編集も必要になります）ので、これはそのままにしておく必要があります。
- sourcefile は、少なくともファイル名から判断すると、ソースコードファイルである可能性が高いものです。
.cで終わるファイル名はCで書かれていると見なされ、.C、.cc、および.c++で終わるファイル名はC ++であると見なされ、ファイル名は.mまたは.mmは、ObjectiveCにあると見なされます。 - cpparg はCプリプロセッサの引数であり、
-I、-D、-U、または-Cで始まるものです。 - ライブラリは、
.aで終わるか、-lまたは-Lで始まるものです。
特定のプラットフォームでプラットフォームに特別なライブラリが必要な場合は、Setupファイルを編集してpython setup.py buildを実行することでライブラリを追加できます。 たとえば、次の行で定義されたモジュールの場合
foo foomodule.c
プラットフォーム上の数学ライブラリlibm.aとリンクする必要があります。次の行に、-lmを追加するだけです。
foo foomodule.c -lm
コンパイラまたはリンカ向けの任意のスイッチは、-Xcompiler arg および-Xlinker arg オプションで提供できます。
foo foomodule.c -Xcompiler -o32 -Xlinker -shared -lm
-Xcompilerおよび-Xlinkerの後の次のオプションが適切なコマンドラインに追加されるため、上記の例では、コンパイラーに-o32オプションが渡され、リンカーは次のようになります。 -sharedに合格しました。 コンパイラオプションに引数が必要な場合は、複数の-Xcompilerオプションを指定する必要があります。 たとえば、-x c++を渡すには、Setupファイルに-Xcompiler -x -Xcompiler c++が含まれている必要があります。
コンパイラフラグは、 CFLAGS環境変数を設定して提供することもできます。 設定すると、 CFLAGSの内容が、Setupファイルで指定されたコンパイラフラグに追加されます。
WindowsでMicrosoft以外のコンパイラを使用する
ボーランド/コードギアC ++
このサブセクションでは、Borland C ++コンパイラバージョン5.5でDistutilsを使用するために必要な手順について説明します。 まず、Borlandのオブジェクトファイル形式（OMF）が、PythonまたはActiveStateWebサイトからダウンロードできるPythonバージョンで使用されている形式とは異なることを知っておく必要があります。 （Pythonは、オブジェクトファイル形式としてCOFFを使用するMicrosoft Visual C ++で構築されています。）このため、Pythonのライブラリpython25.libをBorland形式に変換する必要があります。 これは次のように実行できます。
coff2omf python25.lib python25_bcpp.lib
coff2omfプログラムには、Borlandコンパイラが付属しています。 ファイルpython25.libは、PythonインストールのLibsディレクトリにあります。 拡張機能が他のライブラリ（zlib、…）を使用している場合は、それらも変換する必要があります。
変換されたファイルは、通常のライブラリと同じディレクトリに存在する必要があります。
Distutilsは、名前を変更してこれらのライブラリをどのように使用しますか？ 拡張機能にライブラリが必要な場合（例： foo）Distutilsは、サフィックス_bcppのライブラリが見つかったかどうかを最初にチェックします（例： foo_bcpp.lib）そしてこのライブラリを使用します。 そのような特別なライブラリが見つからない場合は、デフォルト名（foo.lib）を使用します。 1
DistutilsにBorlandC ++で拡張機能をコンパイルさせるには、次のように入力する必要があります。
python setup.py build --compiler=bcpp
Borland C ++コンパイラをデフォルトとして使用する場合は、Distutilsの個人用またはシステム全体の構成ファイルでこれを指定できます（セクション Distutils構成ファイルを参照）。
も参照してください
- C ++ Builderコンパイラ
- ダウンロードページへのリンクを含む、Borlandの無料のC ++コンパイラに関する情報。
- Borlandの無料コンパイラを使用したPython拡張機能の作成
- Borlandの無料のコマンドラインC ++コンパイラを使用してPythonをビルドする方法を説明するドキュメント。
GNU C / Cygwin / MinGW
このセクションでは、CygwinおよびMinGWディストリビューションのGNU C / C ++コンパイラでDistutilsを使用するために必要な手順について説明します。 2 Cygwinで構築されたPythonインタープリターの場合、次の手順を実行しなくてもすべてが機能するはずです。
すべての拡張機能をMinGWまたはCygwinで構築できるわけではありませんが、多くの拡張機能を構築できます。 動作しない可能性が最も高い拡張機能は、C ++を使用する拡張機能、またはMicrosoft VisualC拡張機能に依存する拡張機能です。
DistutilsにCygwinで拡張機能をコンパイルさせるには、次のように入力する必要があります。
python setup.py build --compiler=cygwin
および非cygwinモードのCygwin 3 またはMinGWタイプの場合：
python setup.py build --compiler=mingw32
これらのオプション/コンパイラのいずれかをデフォルトとして使用する場合は、Distutilsの個人用またはシステム全体の構成ファイルに書き込むことを検討してください（セクション Distutils構成ファイルを参照）。
古いバージョンのPythonとMinGW
次の手順は、2.4.1より前のバージョンのPythonと3.0.0より下のMinGW（binutils-2.13.90-20030111-1）を使用している場合にのみ適用されます。
これらのコンパイラには、いくつかの特別なライブラリが必要です。 ライブラリを変換するプログラムがないため、このタスクはBorlandのC ++よりも複雑です。 まず、PythonDLLがエクスポートするシンボルのリストを作成する必要があります。 （このタスクに適したプログラムは https://sourceforge.net/projects/mingw/files/MinGW/Extension/pexports/ にあります）。
pexports python25.dll >python25.def
インストールされるpython25.dllの場所は、インストールオプション、およびWindowsのバージョンと言語によって異なります。 「justforme」インストールでは、インストールディレクトリのルートに表示されます。 共有インストールでは、システムディレクトリに配置されます。
次に、これらの情報からgccのインポートライブラリを作成できます。
/cygwin/bin/dlltool --dllname python25.dll --def python25.def --output-lib libpython25.a
結果のライブラリは、python25.libと同じディレクトリに配置する必要があります。 （Pythonインストールディレクトリの下のlibsディレクトリである必要があります。）
拡張機能が他のライブラリ（zlib、…）を使用している場合は、それらも変換する必要があります。 変換されたファイルは、通常のライブラリと同じディレクトリに存在する必要があります。
脚注
- 1
- これは、既存のすべてのCOFFライブラリを同じ名前のOMFライブラリに置き換えることができることも意味します。
- 2
- 詳細については、 https://www.sourceware.org/cygwin/を確認してください
- 3
- その場合、利用可能なPOSIXエミュレーションはありませんが、
cygwin1.dllも必要ありません。
