<p>名前空間パッケージのpipinstall--editableおよびpipinstallclash</p>

ここで同じ問題:(

このバグをテストするためのコードを投稿しました： http ：

ここでの問題の根本は、setuptoolsに名前空間パッケージを機能させるための2つのメソッドが含まれていることです。 __init__.pyメソッド（文書化されており、人間が使用できます）と...-nspkg.pthファイルメソッドです。 --single-version-externally-managed （pipが使用）でのみ使用されます。 2つの方法は互いに互換性がありません。

IRCでmitsuhikoや他の人と話し合った後、pipの最良の（部分的な）解決策は、「pip install -e」に、開発インストールされたパッケージごとに標準のsetuptools ... nspkg.pthファイルの修正バージョンを追加させることです。 。 （必要な変更は、sitedirの代わりにdevelop egg-linkパスを使用し、開発でインストールされた名前空間パッケージにはinit .pyがあるため、 init .pyのチェックを完全にスキップすることです）。 これは、pipが少なくともそれ自体と互換性があることを意味します（pip-installedおよびpip-editable-installed名前空間パッケージは一緒に機能します）。 Pip-installedおよびsetuptools / distribute-installed名前空間パッケージは互換性がありません。

私も最近これに噛まれました。 それによって引き起こされる別の問題は、名前空間パッケージに__init__.pyがインストールされていないため（その名前空間に1つのパッケージしかインストールしておらず、-single-version-externallymanagedでインストールされていると仮定）です。 noseのモジュール検索を中断します。 たぶんそれは鼻のせいですが、ディレクトリに__init__.pyが含まれていない場合、それがPythonパッケージではないと予想するのは合理的だと思います。

pipはどういうわけかnspkg.pthを完全に強制終了し、 __init__.pyをインストールする必要があると思います。 パッケージ自体が正しく設計されている限り（つまり、extend_path / declare_namespaceを除いて__init__.pyが空である限り）、問題はありません。 --single-version-externally-managedは、システムパッケージャーを念頭に置いて設計されましたが、そもそもpipを使用することはありません。 ですから、あまり邪魔にならずにこの動作を完全に無効にする方法があるのではないかと思います。

'--single-version-externally-managed'から切り替えるための+1：このオプションはpipのユースケースをまったく対象としていません。 pipがeasy_installと同じくらいうまくインストールできない場合、その目的は何ですか？

--single-version-externally-managed完全に切り替えることは起こりません。 フラットインストールは機能です。 名前空間パッケージの場合にのみそれから切り替えることは、これらの問題を回避するために私が検討する可能性です。 私はそれが好きではありませんが、setuptools / distributeに組み込まれている2種類の名前空間パッケージサポートの間に固有の非互換性があることを考えると、優れたオプションはないようです。

--single-version-externally-managedが「ピップのユースケースを対象としていない」と言うのは、間違ったニシンと赤いニシンの間のどこかにあります。 このフラグは、easy_install以外のツールによって管理されるフラットなシングルバージョンのインストールを許可することを目的としています。 それがまさにpipがそれを使用する目的です。 setuptoolsの作成者が元々（そして誤って）システムパッケージャーだけがそのような機能に興味があると思っていたという事実は関係ありません。

ここでの破損は、setuptoolsがそのフラグを持つ名前空間パッケージに使用する手法に固有のバグであり、フラグが元々意図されていたオーディエンスであるシステムパッケージャーによって使用された場合と同じように存在します（「 setup.pydevelop」インストール済みパッケージおよびsystem-package-installed名前空間パッケージ）。

私もこのバグを経験しています。 これは、解決できないバグの1つであり、今後も続くと思います。 しかたがない。

名前空間パッケージが含まれている場合に--single-version-externally-managedを回避するパッチを受け入れます。これにより、この問題は解決すると思います。 現在、そのパッチを作成する予定はありません。

--single-version-externally-managedを使用しないためにpip install渡すことができるオプションはなぜですか？ easy_installと同じように、 ./pip/req.py:568 、すべてのパッケージがeggディレクトリにインストールされたことをコメントアウトしてテストします。 site-packagesがフラットにインストールされるパッケージとそうでないパッケージの両方と混ざらないように、pipとeasy_installの両方を使用した場合にこれを実行したいことがあります。

私はとの問題が表示されていない--eggをオプトアウトするためのオプション--single-version-externally-managed 。

https://github.com/k4ml/pip/commit/93cd6b16207d2eba201a7fc3126624b616f5e6f9

私が正しい方向に進んでいる場合、誰かがコメントできますか？ ピップコードをハッキングするのはこれが初めてなので、 pip install --egg somepackagesをすべて単一のegg dirにインストールするために、その一部を数分間垣間見ることに基づいています。

私が正しい方向に進んでいる場合、誰かがコメントできますか？

私には良さそうです、ただテストが必要です。 テストは主に高レベルです
ScriptTestを使用した統合テストは、に基づいて簡単に記述できるはずです。
既存の例。 この場合、インストールをテストするだけです。
サンプルパッケージは、フラットインストールではなく.eggファイルになります。
サイトパッケージ。 ローカルファイルシステムからパッケージをインストールする必要があります。
ネットワークではありません： tests/packages/FSPkgはおそらく正常に機能します。 追加する
tests/test_basic.pyへのテストは問題ありません。

ありがとう！

プルリクエスト-https：//github.com/pypa/pip/pull/541

また、pip.confでこのフラグを設定できるようにすることも考えています。 あなたはそれについてどう思いますか？

また、pip.confでこのフラグを設定できるようにすることも考えています。 あなたはそれについてどう思いますか？

プルリクエストについて話し合いましょう。

1つの回避策を提供するマージされたプルリクエスト＃541。 ありがとう@ k4ml！

注意：この問題を修正するために追加された--eggオプションは、代替の回避策が提供されずに削除される可能性があります。 ＃1749の説明を参照してください

この問題を実際に再現するためのスクリプトは次のとおりです

https://gist.github.com/Ivoz/d9bff05069e0ec53e6ea

私は--eggソリューションの大ファンではありませんが、これにはそれほど面倒な回避策が必要です。

回避策がないと、開発中に--editableを一度使用してから編集してテストすることはできません。 コードを保存するたびに、 pip install -I --no-deps .を実行する必要があります。これは非常に古く、壊れやすいものです（読んでください：時々忘れます）。

この問題全体が現れる方法に関する問題の一部は、それが沈黙しているということです。 モジュールがインストールされていて、pipがそこにあると通知しても、モジュールをインポートすることはできません。

名前空間内の編集不可能なパッケージがすでにインストールされている名前空間の一部として編集可能なパッケージをインストールしようとすると、pipに文句を言うだけで前向きなステップになります。 または、名前空間内の編集可能なパッケージがすでにインストールされている名前空間の一部である編集不可能なパッケージをインストールしようとした場合は、代わりに文句を言います。

別のオプションとして、実際に名前空間パッケージと編集可能なインストールを常に機能させたい場合は、名前空間パッケージが編集可能としてインストールされている場合、pipはその名前空間内の他のすべてのパッケージを目的のパッケージと一緒に編集可能として再編成できます。

setuptoolshttps ： //bitbucket.org/pypa/setuptools/issue/250/develop-and-install-single-versionでこの問題を修正するための2つの提案を提出しました

パッティング

pkg_resourcesをインポートします。 pkg_resources.fixup_namespace_packages（ ''）

site-packagesの.pthファイルでは、pip install-eがインストールされたものを正しく機能させるのに十分なようです。

これは、両方が編集可能としてインストールされている、同じトップ名前空間を持つ2つのパッケージにも影響します。 2番目のパッケージのインストールが壊れています。

すべてのアプリケーションにグローバル名前空間を使用しているため、この問題は少し難しいです（+ setuptoolsがホイールをサポートしていないという問題。これはWindowsデプロイメントプラットフォームにコンパイラがないために必要です）。 また、Python 3.4を使用したセットアップでは、推奨されるすべてのソリューションが失敗するようです。

pip install -eが編集可能なプロジェクトに対してsetup.py developを実行することに気付いた後、setuptoolsプロシージャにフックし、*。pthファイルを作成しました。このファイルは、Pythonプロセス時に名前空間パッケージを「導入」します。開始します。 これにより、setuptools18とpip7.1.0を使用する際の問題が解決されます。

これを実現する方法を示すsetup.pyファイルの例は、次の場所にあります。
https://gist.github.com/cbrand/a1624ac3e9c81ce45fcb

これが他の人にも役立つことを願っています。

今日もこれに遭遇し、ビルドアウトからvirtualenv + pipに切り替えるのを妨げています。

問題を示す小さなデモを作成しました。 テストするには、.tar.gzを解凍し、その中で{{run-me}}スクリプトを実行します。 修正をテストするときに役立つ場合があります。

私もこの問題にぶつかっています。

理解しようとしているときに、 https： //github.com/pypa/pip/issues/3#issuecomment -1659959で@carljmによって提案された解決策に出くわしました。つまり、_have "pip install-e"が標準の修正バージョンを追加します。開発にインストールされた各package_のsetuptools ... nspkg.pthファイル。

私はそのアプローチを手動で試しましたが、うまくいくようです。 ＃3160で説明されているように、名前空間パッケージが欠落している浅いソースツリーの問題を同時に解決するようです。

それで、そのアプローチがまだ有効であると考えられるかどうか、それを実装する試みがあったかどうか、そしてこれに対するパッチが考慮されるかどうか疑問に思いますか？

それで...これが近い将来修正されるという希望はありませんか？

pkg_resources.get_distribution()副作用により、インポートが機能します。 これは、Pythonシェルが失敗したときに、エントリポイントをロードするコードが正しく機能したときに発見されました。

これは、ipythonシェルがパッケージのインポートに問題がない理由も説明している可能性があります。

このバグがまだ開いていて、5年経っても明確な回避策がないことに驚いています。

フレームワークを1つの統合されたフレームワークにまとめるのが仕事の場合、pipは仕事を無駄にします。 このバグのため、正直なところ、どのように作業を進めるのかわかりません。

これは、主にボランティアが行ったプロジェクトで問題を修正するのは難しいですが、
ピップがこれを正しく行うことができるように、setuptoolsに必要なサポートを自由に追加してください

ブランドンGithubの[email protected]書き込み：

このバグがまだ開いていて、5年経っても明確な回避策がないことに驚いています。

ええ、それは残念です。

あなたの仕事がフレームワークを1つの統合されたフレームワークにまとめることである場合、
ピップはあなたの仕事をひどくします。 正直なところ、どのように進めればいいのかわかりません
このバグによる私の仕事。

私は最近、上記のfixup_namespace_packages（ ''）ハックを適用しました
動作しているようです：venvのサイトパッケージ内にz.pthを作成しました
import pkg_resources; pkg_resources.fixup_namespace_packages('')だけが含まれています

試してみる価値がある、私見。

ここでさらに別のバンプ！

すべての骨髄パッケージが名前空間を利用し（一部のパッケージは最大4つまたは5つになります）、この特定の問題は、新しいユーザーが開発ツールをセットアップするのを支援することに関しては、私の存在の少し悩みの種でした。 。 私はこれを使って60個のパッケージを恥ずかしがり屋にしています。 entry_pointsノートも興味深いものです。名前空間に寄与する事実上すべてのパッケージが、 entry_pointsも寄与するからです。

pipアプローチは、私の経験では、名前空間で連携する_every_パッケージがディスクからインストールされ、編集可能である場合にのみ機能します。 1つのパッケージがpipを介して編集不可能にインストールされている場合、糸のボール全体が解け始め、新しいユーザーにとって非常に鈍い症状が発生します。 （断続的にインポート可能なモジュールなど。親名前空間をインポートしてnamespace.__path___を検証する一般的なサニティチェックにより、テストで原因の破損したパッケージが迅速に特定されました。）適切にpipインストールされたパッケージと純粋なsetup.py develop 'dを混合するただし、ソースのもの（pipを回避する）は機能しているように見えます。

また、単一の名前空間提供パッケージを3つの異なる方法で、場合によってはすべて同時にインストールできるという奇妙な状況に陥ることもあるようです。 （ pip uninstall繰り返し呼び出すと、それぞれがより多くのファイルを見つけるのは、残念なことですが、見るのも楽しいです。） pip install -eを使用する場合の依存関係のインストールも、一貫性がないようです。 ほとんどの場合、適切にアンパックされた名前空間（インストール済み）、pth-linkファイル（インストール済み編集可能）になり、ある場合には、 zip_safeにもかかわらず、zip形式の.eggインストールできました。 zip_safeというFalseその依存パッケージなしで.eggは、PyPI上に提供されているディストリビューション。

名前空間の問題に対するフラストレーションは、仮想環境が最初からやり直すために4回目にナックされた後にピークに達します。 ;）

解決策ではありませんが、いくつかメモを残しました。 「編集可能な」パッケージ、名前空間付きパッケージ、および通常のパッケージを混在させる場合、buildout + mr.developerを使用する方が幸運です。

@lelitが言及した機能するようですが、一部のパッケージ/ビルドも破損します。

pipインストールと編集可能モードで遊んだ後、 @ carljmと同じアイデアを

これは、PEP420が実装された新しいバージョンのPythonでもまだ問題ですか？ （読んでください：Pythonの新しいバージョンに切り替えるのに役立ちますか？）

PEP420スタイルを使用すると、編集可能モードで何度か効果的に役立ちました。

残念ながら、独自の不具合があります。たとえば、setuptoolsのfind_packagesはそれをサポートしていないため、新しいパッケージには次のハックが含まれています。

-    packages=find_packages('src'),
+    packages=['toplevel.child.' + package
+              for package in find_packages('src/toplevel/child/')],

編集可能なすべてのパッケージに-nspkg.pthを追加することを実装した人はいないようです。

この機能のサポートを追加し、 Python3.5以降のPEP-420パッケージと共存する

興味のある人のために、名前空間パッケージがpip install 、 pip install -e 、 python setup.py install 、およびpython setup.py developどのように機能するかを網羅したリストを次に示します。

https://github.com/jonparrott/namespace-pkg-tests/blob/master/table.md

tl; dr：名前空間内の他のすべてのパッケージがpipを使用してインストールされている限り、 pip install -eとpython setup.py developを使用できます。

この問題を解決します。 setuptools 31で再現スクリプトのこれが修正されたようですが、それを超えると、pipでできることは何もありません。

@jonparrott
https://github.com/jonparrott/namespace-pkg-tests/blob/master/table.mdで結果を取得するために使用されたpipとsetuptoolsのバージョンは何ですか？

@dstufftおそらく修正されていることを感謝しますが、証拠として@jonparrottの互換性テーブルを再実行して

@jonparrottの例では、失敗したケースは「 python setup.py install直接使用する（予想されるPython2でのPEP420の失敗を要約できます。これは、pipが関与していない場合でも失敗します。まったく（ python setup.py install + python setup.py develop ）。

このチケットは、 pip install .とpip install -eまたはpython setup.py develop組み合わせ用

@jonparrottによってすでに投稿されたグラフは、このチケットが解決されたことを示しています。ここに残っている問題は、pipではなくpython setup.py install問題です。

テストを再実行したところ、最初に実行したものとすべて同じです。 @dstufftの評価に同意します

@ piotr-dobrogostテストでは、両方の最新バージョンを使用します。 この記事の執筆時点では、pip9.0.1とsetuptools34.3.2です。