site —サイト固有の構成フック
ソースコード： ：source： `Lib / site.py`
このモジュールは初期化中に自動的にインポートされます。インタープリターの -S オプションを使用すると、自動インポートを抑制できます。
このモジュールをインポートすると、 -S が使用されていない限り、サイト固有のパスがモジュール検索パスに追加され、いくつかのビルトインが追加されます。 その場合、このモジュールは、モジュールの検索パスを自動的に変更したり、組み込みに追加したりすることなく、安全にインポートできます。 通常のサイト固有の追加を明示的にトリガーするには、 site.main（）関数を呼び出します。
バージョン3.3で変更： -S を使用している場合でも、パス操作をトリガーするために使用されるモジュールをインポートします。
それは、頭と尾の部分から最大4つのディレクトリを構築することから始まります。 ヘッド部分はsys.prefixとsys.exec_prefixを使用。 空のヘッドはスキップされます。 テール部分には、空の文字列を使用してから、lib/site-packages（Windowsの場合）またはlib/pythonX.Y/site-packages（UnixおよびmacOSの場合）を使用します。 個別のヘッドテールの組み合わせごとに、既存のディレクトリを参照しているかどうかを確認し、参照している場合はsys.pathに追加し、新しく追加された構成ファイルのパスも調べます。
バージョン3.5で変更：「site-python」ディレクトリのサポートが削除されました。
「pyvenv.cfg」という名前のファイルがsys.executableの1つ上のディレクトリに存在する場合、sys.prefixとsys.exec_prefixがそのディレクトリに設定され、サイトパッケージもチェックされます（sys.base_prefixとsys.base_exec_prefixは常にPythonインストールの「実際の」プレフィックス）。 「pyvenv.cfg」（ブートストラップ構成ファイル）に「true」（大文字と小文字を区別しない）以外に設定されたキー「include-system-site-packages」が含まれている場合、システムレベルのプレフィックスでサイトが検索されることはありません。パッケージ; そうでなければ彼らはそうするでしょう。
パス構成ファイルは、名前がname.pthの形式で、上記の4つのディレクトリのいずれかに存在するファイルです。 その内容は、sys.pathに追加される追加アイテム（1行に1つ）です。 存在しないアイテムがsys.pathに追加されることはなく、アイテムがファイルではなくディレクトリを参照していることは確認されません。 sys.pathに2回以上アイテムが追加されることはありません。 空白行と#で始まる行はスキップされます。 importで始まる行（その後にスペースまたはタブが続く）が実行されます。
ノート
.pthファイルの実行可能行は、特定のモジュールが実際に使用されるかどうかに関係なく、Pythonの起動ごとに実行されます。 したがって、その影響は最小限に抑える必要があります。 実行可能行の主な目的は、対応するモジュールをインポート可能にすることです（サードパーティのインポートフックをロードし、 PATHなどを調整します）。 その他の初期化は、モジュールの実際のインポート時に行われることになっています。 コードチャンクを1行に制限することは、ここにもっと複雑なものを置くことを思いとどまらせるための意図的な手段です。
たとえば、sys.prefixとsys.exec_prefixが/usr/localに設定されているとします。 次に、PythonXYライブラリが/usr/local/lib/pythonX.Yにインストールされます。 これにサブディレクトリ/usr/local/lib/pythonX.Y/site-packagesがあり、3つのサブサブディレクトリfoo、bar、spam、および2つのパス構成ファイルfoo.pthと[ X156X] 。 foo.pthに次のものが含まれていると仮定します。
# foo package configuration
foo
bar
bletch
bar.pthには次のものが含まれます。
# bar package configuration
bar
次に、次のバージョン固有のディレクトリがsys.pathにこの順序で追加されます。
/usr/local/lib/pythonX.Y/site-packages/bar
/usr/local/lib/pythonX.Y/site-packages/foo
bletchは存在しないため、省略されていることに注意してください。 barディレクトリはfooディレクトリの前にあります。これは、bar.pthがアルファベット順にfoo.pthの前にあるためです。 spamは、どちらのパス構成ファイルにも記載されていないため、省略されています。
これらのパス操作の後、sitecustomizeという名前のモジュールをインポートしようとします。このモジュールは、任意のサイト固有のカスタマイズを実行できます。 これは通常、システム管理者によってsite-packagesディレクトリに作成されます。 このインポートが ImportError またはそのサブクラス例外で失敗し、例外のname属性が'sitecustomize'と等しい場合、それは黙って無視されます。 Windowsのpythonw.exe（デフォルトでIDLEの起動に使用されます）のように、Pythonが出力ストリームを使用せずに起動された場合、sitecustomizeからの出力の試行は無視されます。 その他の例外は、プロセスのサイレントでおそらく不可思議な失敗を引き起こします。
この後、 ENABLE_USER_SITE がtrueの場合、usercustomizeという名前のモジュールをインポートしようとします。このモジュールは任意のユーザー固有のカスタマイズを実行できます。 このファイルは、 -s によって無効にされない限り、sys.pathの一部であるユーザーsite-packagesディレクトリ（以下を参照）に作成されることを目的としています。 このインポートが ImportError またはそのサブクラス例外で失敗し、例外のname属性が'usercustomize'と等しい場合、それは黙って無視されます。
一部の非Unixシステムでは、sys.prefixとsys.exec_prefixが空であり、パス操作がスキップされることに注意してください。 ただし、sitecustomizeおよびusercustomizeのインポートは引き続き試行されます。
Readline構成
readline をサポートするシステムでは、Pythonがインタラクティブモードで起動され、 -Sがない場合、このモジュールは rlcompleter モジュールもインポートして構成します。 オプション。 デフォルトの動作は、タブ補完を有効にし、履歴保存ファイルとして~/.python_historyを使用することです。 無効にするには、sitecustomizeまたはusercustomizeモジュールまたは PYTHONSTARTUP の sys .__ Interactivehook __ 属性を削除（またはオーバーライド）します。 ] ファイル。
バージョン3.4で変更： rlcompleterと履歴のアクティブ化が自動化されました。
モジュールの内容
- site.PREFIXES
- サイトパッケージディレクトリのプレフィックスのリスト。
- site.ENABLE_USER_SITE
- ユーザーsite-packagesディレクトリのステータスを示すフラグ。
Trueは、有効になっていてsys.pathに追加されたことを意味します。Falseは、ユーザーの要求によって無効にされたことを意味します（ -s または PYTHONNOUSERSITE を使用）。Noneは、セキュリティ上の理由（ユーザーまたはグループIDと有効IDの不一致）または管理者によって無効にされたことを意味します。
- site.USER_SITE
- ユーザーサイトへのパス-実行中のPythonのパッケージ。 getusersitepackages（）がまだ呼び出されていない場合は、
Noneにすることができます。 デフォルト値は、UNIXおよび非フレームワークmacOSビルドの場合は~/.local/lib/pythonX.Y/site-packages、macOSフレームワークビルドの場合は~/Library/Python/X.Y/lib/python/site-packages、Windowsの場合は%APPDATA%\Python\PythonXY\site-packagesです。 このディレクトリはサイトディレクトリです。つまり、その中の.pthファイルが処理されます。
- site.USER_BASE
- ユーザーsite-packagesのベースディレクトリへのパス。 getuserbase（）がまだ呼び出されていない場合は、
Noneにすることができます。 デフォルト値は、UNIXおよびmacOS非フレームワークビルドの場合は~/.local、macOSフレームワークビルドの場合は~/Library/Python/X.Y、Windowsの場合は%APPDATA%\Pythonです。 この値は、スクリプト、データファイル、Pythonモジュールなどのインストールディレクトリを計算するためにDistutilsによって使用されます。 ユーザーインストールスキームの場合。 PYTHONUSERBASE も参照してください。
- site.main()
すべての標準サイト固有のディレクトリをモジュール検索パスに追加します。 この関数は、Pythonインタープリターが -S フラグで開始されていない限り、このモジュールがインポートされるときに自動的に呼び出されます。
バージョン3.3で変更：この関数は以前は無条件に呼び出されていました。
- site.addsitedir(sitedir, known_paths=None)
- sys.pathにディレクトリを追加し、その
.pthファイルを処理します。 通常、sitecustomizeまたはusercustomizeで使用されます（上記を参照）。
- site.getsitepackages()
すべてのグローバルサイトパッケージディレクトリを含むリストを返します。
バージョン3.2の新機能。
- site.getuserbase()
ユーザーベースディレクトリのパス USER_BASE を返します。 まだ初期化されていない場合、この関数は PYTHONUSERBASE を尊重して設定します。
バージョン3.2の新機能。
- site.getusersitepackages()
ユーザー固有のサイトパッケージディレクトリ USER_SITE のパスを返します。 まだ初期化されていない場合、この関数は USER_BASE を尊重して設定します。 ユーザー固有のサイトパッケージが
sys.pathに追加されたかどうかを判断するには、 ENABLE_USER_SITE を使用する必要があります。バージョン3.2の新機能。
コマンドラインインターフェイス
site モジュールは、コマンドラインからユーザーディレクトリを取得する方法も提供します。
$ python3 -m site --user-site
/home/user/.local/lib/python3.3/site-packages
引数なしで呼び出された場合、 sys.path の内容が標準出力に出力され、続いて USER_BASE の値とディレクトリが存在するかどうかが出力され、同じことが USER_SITE 、最後に ENABLE_USER_SITE の値。
- --user-base
- ユーザーベースディレクトリへのパスを出力します。
- --user-site
- ユーザーsite-packagesディレクトリへのパスを出力します。
両方のオプションを指定すると、ユーザーベースとユーザーサイトが os.pathsep で区切られて（常にこの順序で）印刷されます。
オプションを指定すると、スクリプトは次のいずれかの値で終了します。ユーザーのsite-packagesディレクトリが有効になっている場合は0、ユーザーによって無効にされている場合は1、 [ X175X]セキュリティ上の理由または管理者によって無効にされている場合。エラーがある場合は2より大きい値。
