site --- サイト固有の設定フック

ソースコード: Lib/site.py

このモジュールは初期化中に自動的にインポートされます。 自動インポートはインタプリタの -S オプションで禁止できます。

通常、このモジュールをインポートすると、サイト固有のパスをモジュール検索パスに追加し、help() などの 呼び出し可能オブジェクト を組み込み名前空間に追加します。 ただし、Python の起動オプション -S はこの処理を抑制します。 その場合は、モジュール検索パスの自動変更や組み込み名前空間への追加を行わずに、このモジュールをインポートできます。 通常のサイト固有の追加処理を明示的に行うには、main() 関数を呼び出してください。

バージョン 3.3 で変更: 以前は -S を使っているときでも、モジュールをインポートするとパス変更が起動されていました。

まず、先頭部分と末尾部分を組み合わせて、最大四つのディレクトリを構成します。 先頭部分には sys.prefix と sys.exec_prefix を使い、空のものは省きます。 末尾部分には、空文字列と、Windows では lib/site-packages、Unix と macOS では lib/pythonX.Y[t]/site-packages を使います。 (省略可能な接尾辞 "t" は フリースレッドビルド を表し、sys.abiflags 定数に "t" が含まれる場合に付けます。) 先頭と末尾の異なる組み合わせごとに、ディレクトリが存在するかを調べます。 存在すれば sys.path に追加し、追加したパスに設定ファイルがあるかも調べます。

バージョン 3.5 で変更: "site-python" ディレクトリのサポートは削除されました。

バージョン 3.13 で変更: Unix では、フリースレッド の Python インストールは、lib/python3.13t/ のように、バージョン別ディレクトリ名の接尾辞 "t" で識別します。

バージョン 3.14 で変更: 仮想環境 で sys.prefix と sys.exec_prefix を更新する処理は、site の役割ではなくなりました。 現在は パスの初期化 中に行います。 その結果、仮想環境 の sys.prefix と sys.exec_prefix は site の初期化に依存しなくなり、-S の影響を受けなくなりました。

仮想環境 で実行する場合、sys.prefix 内の pyvenv.cfg ファイルからサイト固有の設定を確認します。 include-system-site-packages キーがあり、値が true (大文字・小文字は区別しません) の場合、システムレベルのプレフィックスで site-packages を探します。 そうでなければ探しません。 システムレベルのプレフィックスを検索しない場合は、ユーザサイトのプレフィックスでも site-packages を暗黙的に検索しなくなります。

site モジュールは、パス設定用の name.pth と、ユーザコードの最初の行より前にコードを実行するための name.start という二種類の起動設定ファイルを認識します。 どちらも、上記の四つのディレクトリのいずれかに置けます。 各ディレクトリ内では、ファイル名のアルファベット順に並べ、その順に解析します。

パスの追加 (.pth ファイル)

name.pth には、sys.path に追加する項目を一行に一つずつ記述します。 存在しないディレクトリを指す項目は sys.path に追加しませんが、項目がファイルではなくディレクトリを指すかどうかは確認しません。 同じ項目を sys.path に二度追加することはありません。 空行と # で始まる行は読み飛ばします。

後方互換性のため、import の後にスペースまたはタブが続く行は、exec() で実行します。

バージョン 3.13 で変更: .pth ファイルは、最初に UTF-8 で、失敗した場合は locale encoding でデコードされるようになります。

バージョン 3.15 で変更: .pth ファイルで import から始まる行は非推奨です。 非推奨の期間中も、下記の場合を除いて実行されますが、-v フラグを指定した場合にだけ診断メッセージを出力します。

対応する name.start ファイルが存在する場合、name.pth 内の import 行は通知せずに無視します。

個々の行でエラーが起きても、ファイルの残りの処理を中止しなくなりました。 エラーごとに報告し、残りの行の処理を続けます。

バージョン 3.15 で非推奨、バージョン 3.20 で削除予定: name.pth ファイルを utf-8-sig 以外のエンコーディングでデコードすることは Python 3.15 で非推奨になり、ロケールのエンコーディングによるデコードのサポートは Python 3.20 で削除されます。

name.pth ファイルの import 行は非推奨で、Python 3.18 と 3.19 では通知せずに無視します。 Python 3.20 では、name.pth ファイルの import 行に対して警告を出します。

起動時エントリーポイント (.start ファイル)

Added in version 3.15.

起動時エントリーポイントのファイルは、name.start という形式の名前を持ち、上記の site-packages ディレクトリのいずれかに存在するファイルです。 各ファイルでは、pkgutil.resolve_name() が解釈する pkg.mod:callable 構文を使って、インタープリタの起動時に呼び出すエントリーポイントを指定します。

空行でも # で始まる行でもない各行には、pkg.mod:callable 形式のエントリーポイントへの参照が必要です。 コロンと呼び出し可能オブジェクトの部分は必須です。 各オブジェクトは引数なしで呼び出され、戻り値は破棄されます。

.start ファイルは、.pth によるパスの追加をすべて sys.path に適用した後で処理します。 これにより、起動時のコードが実行される前に各パスを利用できるようにします。

.pth ファイルによる sys.path への追加とは異なり、重複したエントリーポイントは まとめません。 同じエントリーポイントが複数回現れれば、複数回呼び出します。

エントリーポイントの解決や呼び出し中に例外が起きると、sys.stderr にトレースバックを表示し、残りのエントリーポイントの処理を続けます。

.start ファイルは UTF-8 でエンコードする必要があります。

これらの機能の最初の仕様は PEP 829 で定義されました。

注釈

同じベース名の name.pth と name.start が同じ場所にある場合、.pth の import 行を無視し、.start のエントリーポイントを使います。

注釈

実行可能な行 (name.pth の import 行と name.start のエントリーポイント) は、そのモジュールが実際に使われるかどうかに関係なく、Python の起動時に実行します。 ただし、-S で site.py モジュール全体を無効にした場合は除きます。

注釈

name.start ファイルは pkgutil.resolve_name() を strict=True で呼び出すため、完全な pkg.mod:callable 形式が必要です。

起動設定ファイルの例

例えば、sys.prefix と sys.exec_prefix が /usr/local に設定されているとします。 このとき、Python X.Y のライブラリは /usr/local/lib/pythonX.Y にインストールされています。 その下に /usr/local/lib/pythonX.Y/site-packages があり、さらに foo、bar、spam の三つのサブディレクトリと、foo.pth、bar.pth の二つのパス設定ファイルがあるとします。 foo.pth の内容は次のとおりとします。

# foo パッケージの設定

foo
bar
bletch

また、 bar.pth には:

# bar パッケージの設定

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 はどちらのパス設定ファイルにも記載されていないため、省略されます。

さらに、次の内容の foo.start ファイルもあるとします。

# foo パッケージの起動時コード

foo.submod:initialize

この場合、上記のように sys.path を拡張した後、Python がユーザコードに制御を渡す前に、foo.submod モジュールをインポートし、そのモジュールの initialize() 関数を呼び出します。

.pth ファイルの import 行から .start ファイルへの移行

現在パッケージに name.pth ファイルを含めている場合、sys.path にパスを追加する行はすべてそのままにできます。 移行が必要なのは import 行だけです。

移行するには、パッケージ内のインポート可能なモジュールに、引数を取らない呼び出し可能オブジェクトを作成します。 対応する name.start ファイルから、pkg.mod:callable 形式のエントリーポイントとして参照してください。 import 行の最初のセミコロンより後の処理をすべて callable() 関数へ移します。

PEP 829 に対応しない古い Python と、対応する新しい Python の両方をサポートする必要がある場合は、name.pth の import 行を次の形に変更してください。

import pkg.mod; pkg.mod.callable()

古い Python はこの import 行を実行し、新しい Python はそれを無視して name.start ファイルを使います。 両方に対応する期間が終わったら、.pth ファイルからすべての import 行を削除してください。

sitecustomize

After these path manipulations, an attempt is made to import a module named sitecustomize, which can perform arbitrary site-specific customizations. It is typically created by a system administrator in the site-packages directory. If this import fails with an ImportError or its subclass exception, and the exception's name attribute equals 'sitecustomize', it is silently ignored. If Python is started without output streams available, as with pythonw.exe on Windows (which is used by default to start IDLE), attempted output from sitecustomize is ignored. Any other exception causes a silent and perhaps mysterious failure of the process.

usercustomize

その後、ENABLE_USER_SITE が真の場合は、ユーザ固有の任意のカスタマイズを行う usercustomize モジュールのインポートを試みます。 このファイルは、下記のユーザ site-packages ディレクトリに作成することを想定しています。 このディレクトリは、-s で無効にしない限り sys.path に含まれます。 インポートが ImportError またはそのサブクラスの例外で失敗し、例外の name 属性が 'usercustomize' の場合は、通知せずに無視します。

一部の非 Unix システムでは、sys.prefix と sys.exec_prefix が空のため、パスの変更は行いません。 ただし、sitecustomize と usercustomize のインポートは試みます。

readline の設定

readline に対応するシステムで、-S オプションなしで Python を 対話モード で起動した場合、このモジュールは rlcompleter のインポートと設定も行います。 デフォルトではタブ補完を有効にし、履歴の保存先として ~/.python_history を使います。 無効にするには、sitecustomize、usercustomize、または PYTHONSTARTUP のファイルで sys.__interactivehook__ 属性を削除するか置き換えてください。

バージョン 3.4 で変更: rlcompleter とhistory のアクティベーションが自動で行われるようになりました。

モジュールの内容

site.PREFIXES

siteパッケージディレクトリのprefixのリスト。

site.ENABLE_USER_SITE

ユーザサイトディレクトリのステータスを示すフラグ。 True の場合、ユーザサイトディレクトリが有効で sys.path に追加されていることを意味しています。 False の場合、ユーザによるリクエスト(オプション -s か PYTHONNOUSERSITE)によって、 None の場合セキュリティ上の理由(ユーザまたはグループIDと実効IDの間のミスマッチ)あるいは管理者によって、ユーザサイトディレクトリが無効になっていることを示しています。

site.USER_SITE

実行中の Python のユーザ site-packages ディレクトリへのパスです。 getusersitepackages() をまだ呼び出していない場合は None のこともあります。 デフォルトは、UNIX と非フレームワークの macOS ビルドでは ~/.local/lib/pythonX.Y[t]/site-packages、macOS のフレームワークビルドでは ~/Library/Python/X.Y/lib/python/site-packages、Windows では %APPDATA%\Python\PythonXY\site-packages です。 省略可能な "t" はフリースレッドビルドを示します。 これはサイトディレクトリなので、内部の .pth ファイルは処理されます。

site.USER_BASE

ユーザの site-packages のベースとなるディレクトリへのパスです。 getuserbase() がまだ呼び出されていなければ None かもしれません。デフォルト値は UNIX と frameworkなしの macOS ビルドでは ~/.local 、macOS framework ビルドでは ~/Library/Python/X.Y 、Windows では %APPDATA%\Python です。この値は、スクリプト、データファイル、Python モジュールなどのインストール先のディレクトリを ユーザーインストールスキーム で計算するのに使われます。 PYTHONUSERBASE も参照してください。

site.main()

モジュール検索パスに標準のサイト固有ディレクトリを追加します。この関数は、Python インタプリタが -S で開始されていない限り、このモジュールインポート時に自動的に呼び出されます。

バージョン 3.3 で変更: この関数は以前は無条件に呼び出されていました。

site.makepath(*paths)

paths を os.path.join() で結合し、os.path.abspath() で絶対パスへの変換を試みます。 絶対パスと、そのパスを os.path.normcase() で大文字・小文字について正規化したものを、二要素のタプルで返します。 os.path.abspath() が OSError を送出した場合は、結合したパスをそのまま大文字・小文字の正規化に使います。

戻り値のタプルの二番目の要素は、大文字・小文字を区別しないファイルシステムでパスを比較するために、site 全体で使われます。 また、このモジュールの各 API で sys.path の重複を防ぐ known_paths 集合に格納する形式でもあります。

class site.StartupState(known_paths=None)

このクラスのインスタンスは、一つ以上のサイトディレクトリから、インタープリタ起動時の設定データを蓄積します。 複数のサイトディレクトリにまたがる .pth と .start の処理をまとめるための推奨インターフェースです。 すべての sys.path への追加を、起動時のコードの実行前に反映できます。

省略可能な known_paths 引数は、大文字・小文字について正規化したパスの集合で、makepath() で作成できます。 sys.path の項目の重複を防ぐために使います。 None (デフォルト) の場合、現在の sys.path から集合を作成します。 main() は、このクラスのインスタンスを暗黙的に使います。

典型的な使い方は次のとおりです。

state = site.StartupState()
for sitedir in site_dirs:
    state.addsitedir(sitedir)
state.process()

Added in version 3.15.

addsitedir(sitedir)

sitedir 内の .pth と .start を読み、sys.path への追加、非推奨の .pth の import 行、.start のエントリーポイントを、この状態オブジェクトに記録します。 記録したデータは、process() を呼び出すまで適用しません。

addusersitepackages()

ユーザごとの site-packages ディレクトリが有効で、存在する場合に追加します。 そのディレクトリの起動設定データを蓄積し、後で process() により処理します。

addsitepackages(prefixes=None)

prefixes から計算したグローバルの site-packages ディレクトリを追加します。 prefixes が None の場合は、グローバルの PREFIXES を使います。 各ディレクトリの起動設定データを蓄積し、後で process() により処理します。

process()

蓄積した状態を適用します。 まずパスの追加を sys.path に反映し、次に .start のエントリーポイントと、.pth の import 行 (非推奨) を実行します。

このメソッドは冪等ではなく、同じインスタンスに対して複数回呼び出してはいけません。 複数回呼び出すと、蓄積した状態を繰り返し適用し、エントリーポイントや import 行を再実行します。

site.addsitedir(sitedir, known_paths=None)

ディレクトリを sys.path に追加し、その中の .pth と .start を解析します。 通常は、上記の sitecustomize または usercustomize で使います。

known_paths 引数は、大文字・小文字について正規化したパスの集合で、sys.path の項目の重複を防ぐために使います。 省略可能で、None (デフォルト) の場合は現在の sys.path から集合を作成します。

複数のサイトディレクトリをまとめて処理するには、StartupState を明示的に作り、その StartupState.addsitedir() を呼び出してください。 .pth と .start の処理を、一回の StartupState.process() 呼び出しまで遅らせるため、すべての sys.path への追加を、起動時のコードの実行前に反映できます。

バージョン 3.15 で変更: .start ファイルも処理するようになりました。 起動時エントリーポイント (.start ファイル) を参照してください。

site.getsitepackages(prefixes=None)

全てのグローバルな site-packages ディレクトリのリストを返します。

prefixes に指定した各ディレクトリ (None の場合は PREFIXES) について、システム環境に応じた site-packages サブディレクトリを計算し、そのフルパスのリストを返します。 パスが存在するかどうかは確認しません。

Added in version 3.2.

バージョン 3.3 で変更: 省略可能な prefixes 引数が追加されました。

site.getuserbase()

ユーザのベースディレクトリへのパス USER_BASE を返します。未初期化であればこの関数は PYTHONUSERBASE を参考にして、設定もします。

Added in version 3.2.

site.getusersitepackages()

ユーザ固有の site パッケージのディレクトリへのパス USER_SITE を返します。未初期化であればこの関数は USER_BASE を参考にして、設定もします。 ユーザ固有の site パッケージが sys.path に追加されたかどうかを確認するには ENABLE_USER_SITE を使ってください。

Added in version 3.2.

コマンドライン・インターフェース

site モジュールは、コマンドラインからユーザディレクトリを取得する方法も提供しています。

$ python -m site --user-site
/home/user/.local/lib/python3.11/site-packages

引数なしで呼び出された場合、sys.path の中身を表示し、続けて USER_BASE とそのディレクトリが存在するかどうか、 USER_SITE とそのディレクトリが存在するかどうか、最後に ENABLE_USER_SITE の値を、標準出力に出力します。

--user-base

ユーザのベースディレクトリを表示します。

--user-site

ユーザの site-packages ディレクトリを表示します。

両方のオプションが指定された場合、ユーザのベースとユーザの site が(常にこの順序で) os.pathsep 区切りで表示されます。

いずれかのオプションが与えられた場合に、このスクリプトは次のいずれかの終了コードで終了します: ユーザの site-packages が有効ならば 0 、ユーザにより無効にされていれば 1 、セキュリティ的な理由あるいは管理者によって無効にされている場合 2 、そして何かエラーがあった場合は 2 より大きな値。

参考