これはひどい問題で、エコシステムにとってかなりの落とし穴だね。例えば、俺はRNGの使用分析のためにtool_name/random.pyを使ったツールを作ったんだけど、そのディレクトリ内で実行されるコマンドはbuiltinのimport randomを隠しちゃうんだ。だから、そのディレクトリからblackフォーマッターを実行できなかった。ローカルのrandom.pyを誤ってインポートしちゃうからね。解決策は、Pythonのフラグを更新して-Iを含めること。そうすれば、Pythonは隔離モードで実行される。これはPEP-668の実装に対する俺のフラストレーションにも関係してる。Pythonは長い間、システムライブラリの偶発的な上書きの問題を抱えてる。もしsudo python -mpip install fooを実行すると、ディストリビューションのsudo apt-get install python-fooと非常に悪い相互作用を起こす可能性がある。pipがapt-getで管理されるべきファイルを追加/削除するからね。でも、これを防ぐための警告を追加する際に、~/.local/pythonX.Y/site-packagesにも同じ警告を適用しちゃった。ここは通常、ユーザーがpython -mpip --local fooで追加パッケージをインストールする場所だから。主張としては、これは/usr/bin/pythonのインポートパスの一部だから、ユーザーのsite-packagesへのインストールもブロックすべきだってこと。これはPEP-668の目的を「ファイル所有権の競合を避ける」から「システムツールのための隔離されたPython環境を確保する」に変えてしまう手品みたいなもんだ。もし俺が/usr/bin/pythonのインポートがディストリビューション管理のインストールだけに影響されるべきだという主張を受け入れるなら、どこでも*.pyファイルを作ることも禁止されるべきだよね。だって、作業ディレクトリにあったらインポートされるんだから。これは明らかにおかしいし、システムレベルの隔離されたPythonを持つためにユーザーレベルのsite-packagesを壊すのが正当化されるとは思えない。正しい解決策は、ディストリビューション管理のプログラムが#!/usr/bin/python -Iをシェバンとして使うことだよ。そうすれば、実際に隔離された環境が得られるのに。結局、PEP-668はユーザーレベルのsite-packagesを無駄に壊して、解決しようとした問題すら解決できなかったんだ。