3.3。 セットアップ構成ファイルの書き込み
多くの場合、ディストリビューションアプリオリを構築するために必要なすべてを書き留めることは不可能です。続行するには、ユーザーまたはユーザーのシステムから情報を取得する必要がある場合があります。 その情報がかなり単純である限り（たとえば、Cヘッダーファイルまたはライブラリを検索するためのディレクトリのリスト）、ユーザーが編集できるように構成ファイルsetup.cfgを提供することは、安価で簡単な方法です。それ。 構成ファイルを使用すると、コマンドオプションのデフォルト値を指定することもできます。このデフォルト値は、インストーラーがコマンドラインで、または構成ファイルを編集することで上書きできます。
セットアップ構成ファイルは、セットアップスクリプト（理想的にはインストーラー 1 に対して不透明）と、制御の範囲外で完全にセットアップスクリプトへのコマンドラインとの間の便利な中間点です。インストーラーまで。 実際、setup.cfg（およびターゲットシステムに存在するその他のDistutils構成ファイル）は、セットアップスクリプトの内容の後、コマンドラインの前に処理されます。 これにはいくつかの有用な結果があります。
- インストーラーは、
setup.cfgを編集することにより、setup.pyに入れたものの一部をオーバーライドできます。 setup.pyで簡単に設定できないオプションに非標準のデフォルトを指定できます- インストーラーは、
setup.pyのコマンドラインオプションを使用して、setup.cfg内のすべてをオーバーライドできます。
構成ファイルの基本的な構文は単純です。
[command]
option=value
...ここで、コマンドはDistutilsコマンドの1つです（例： build_py 、 install ）、および option は、コマンドがサポートするオプションの1つです。 コマンドごとに任意の数のオプションを指定でき、ファイルには任意の数のコマンドセクションを含めることができます。 '#'文字から行の終わりまで続くコメントと同様に空白行は無視されます。 長いオプション値は、継続行をインデントするだけで複数の行に分割できます。
ユニバーサル--helpオプションを使用して、特定のコマンドでサポートされているオプションのリストを確認できます。
$ python setup.py --help build_ext
[...]
Options for 'build_ext' command:
--build-lib (-b) directory for compiled extension modules
--build-temp (-t) directory for temporary files (build by-products)
--inplace (-i) ignore build-lib and put compiled extensions into the
source directory alongside your pure Python modules
--include-dirs (-I) list of directories to search for header files
--define (-D) C preprocessor macros to define
--undef (-U) C preprocessor macros to undefine
--swig-opts list of SWIG command line options
[...]
コマンドラインで--foo-barと綴られているオプションは、構成ファイルではfoo_barと綴られていることに注意してください。
たとえば、拡張機能を「インプレース」で構築する必要があるとします。つまり、拡張機能pkg.extがあり、コンパイルされた拡張機能ファイル（Unixではext.soなど）が必要です。純粋なPythonモジュールpkg.mod1およびpkg.mod2と同じソースディレクトリに配置されます。 コマンドラインで--inplaceオプションをいつでも使用して、次のことを確認できます。
python setup.py build_ext --inplaceただし、これには常に build_ext コマンドを明示的に指定し、--inplaceを指定することを忘れないでください。 より簡単な方法は、このディストリビューションの構成ファイルであるsetup.cfgでエンコードすることにより、このオプションを「設定して忘れる」ことです。
[build_ext]
inplace=1これは、 build_ext を明示的に指定するかどうかに関係なく、このモジュール配布のすべてのビルドに影響します。 ソースディストリビューションにsetup.cfgを含めると、エンドユーザーのビルドにも影響します。拡張機能を常にインプレースでビルドするとモジュールディストリビューションのインストールが中断されるため、このオプションはおそらくお勧めできません。 ただし、特定の特殊なケースでは、モジュールはインストールディレクトリに直接構築されるため、これはおそらく便利な機能です。 （ただし、インストールディレクトリにビルドされることを期待する拡張機能を配布することは、ほとんどの場合、悪い考えです。）
別の例：特定のコマンドは、実行ごとに変更されない多くのオプションを取ります。 たとえば、 bdist_rpm は、RPMディストリビューションを作成するための「スペック」ファイルを生成するために必要なすべてを知っている必要があります。 この情報の一部はセットアップスクリプトから取得され、一部はDistutilsによって自動的に生成されます（インストールされているファイルのリストなど）。 ただし、その一部は bdist_rpm のオプションとして提供する必要があり、実行するたびにコマンドラインで実行するのは非常に面倒です。 したがって、これはDistutils自身のsetup.cfgからのスニペットです。
[bdist_rpm]
release = 1
packager = Greg Ward <[email protected]>
doc_files = CHANGES.txt
README.txt
USAGE.txt
doc/
examples/doc_filesオプションは、読みやすくするために複数行に分割された空白で区切られた文字列であることに注意してください。
脚注
- 1
- この理想は、自動構成がDistutilsによって完全にサポートされるまでおそらく達成されません。
