Pip: pip9.0.2の `importpip`でエラーが発生しました

これも確認できます。 ちょうど同じ問題を提出しようとしています。

これは＃5079の複製です。pipのインポートはサポートされているユースケースではありません（サポートされたことはありません）。

さあ..単一のx.x.PATCHバージョンバンプで大きな重大な変更を加えますか？ 「メイン」と呼ばれるトップレベルのメソッドの場合は？ それはかなり悪い形だと思います。

これもAnacondaを壊し、 @ Miserlouと同じ解決策を思いつきました。

https://github.com/ContinuumIO/anaconda-issues/issues/8911

多くのプロジェクトでエラーが報告されています。

このエラーは、pipを使用してanaconda-navigatorを更新しようとしたときにも気になりました。

これを修正する9.0.3を入手する可能性はありますか？理想的にはすぐにですか？

これはすでに多くの主要なプロジェクト（Anaconda、SpaCy、Zappa）に影響を及ぼしており、GitHubだけで85万回以上の使用があり、この想定される「パッチ」バージョンの更新によって壊れています。

少なくとも9.0.3でこの大規模な変更を元に戻し、その後、将来の10.xxまたは少なくとも9.xxリリースでこの動作を変更する意図をダウンストリームに_アナウンス_できますか？

古いバージョンも使いたくないのですが、それがまさに私たちがやったことです。 9.0.2は、少なくとも現時点では、CI環境内には存在しません。

一部のOpenStackプロジェクトでもこのヒットが見られます。

ピップ10は約1か月で期限が切れます。 私が理解しているように、問題はimport pipを使用してpipの内部機能にアクセスするコードにあります。 このような使用法を公式にサポートしたことはなく、サポートの欠如をしばらくの間明示的に文書化しています（ただし、https：//pip.pypa.io/en/latest/user_guideの「最新」バージョンのドキュメントのみです）。 /＃using-pip-from-your-program、そのドキュメントセクションが追加されてから新しい安定したリリースがないため）。 また、昨年10月に、内部APIの使用がサポートされていないことを明確にするために、内部の再編成を発表しました（https://mail.python.org/pipermail/distutils-sig/2017-October/031642.htmlを参照）。 その変更はpip10にあり、可能なpip 9.0.3リリースがどのpipを実行するかに関係なく、そのような使用法を壊します。 したがって、これを突然の予期しない破損と見なすことは困難です。

@dstufftが緊急の9.0.3リリースを作成したい場合は、それで問題ありません。 しかし、それは非常に短期的な利益にすぎず、人々がまだimport pipから離れていないことに少しがっかりしています。 この問題に見舞われた人々は、まだピップ10の準備をする必要があり、単にimport pip._internalに切り替えることは、私たちがサポートまたは推奨するものではないことを理解する必要があります。

あるレベルのAPIサポートを再導入する提案は確かにオプションですが（たとえば＃5080を参照）、この段階では、そのような変更をpip10にするのは遅すぎます。

古い方法を使用している人のためにコードによって警告が出されることはなく、これが_で始まる「内部」であることを示すものはなく、これは単なるバグ修正のバンプであり、実際にはこれを突然の予期しない破損と見なすのは非常に簡単だと思います。

はい、これは人々がMAJORバージョンアップデートから期待できるタイプの変更です。 それは大丈夫だろう。

残念ながら、この大規模な変更はPATCHの更新で発生しました。これは、_問題を修正するのではなく、修正することを目的としています_。 これは、セマンティックバージョニングの正反対です。 その結果、Pythonエコシステム全体に甚大な被害が発生しています。

この変更をできるだけ早く別のPATCH更新で元に戻してから、主要な重大な変更をMAJORバージョン更新で行う必要があります。 あなたはすでにすべての人のために時期尚早にすべてを壊したので、私は彼らが実際の大きな変化が来ていることをもっと知っていると思います。

また、これは安定したドキュメントに文書化されていないことを考えると、これはすでに文書化されて発表されていると言うのは警官だと思います。また、発表では、1か月のパッチではなく、メジャーバージョンで中断が発生すると述べていました。前。

どうか、みんなの大きな頭痛の種を救い、この問題を元に戻して、実際にセマンティックバージョニングを順守し始めてください。

@Miserlouわかりました、私はあなたのポイントを取ります-それはメジャーバージョンであるため、私たちはpip10の内部の名前変更の変更を対象としました。 パッチリリースのドライバーはよくわかりません- @ dstufftが私にpingを送信し、TLSサポートの差し迫った締め切りが迫ったとき（pip 10リリースの前）にMacOSユーザーの重大な破損を回避するようです。 問題は、短期間のパッチリリースを保証するのに十分なほど重大であると予想しました。 確かに、既存の使用法を壊す意図はありませんでした。

フォローアップ9.0.3の決定を@dstufftに任せなければなりません-9.0.2に何が入ったかの詳細がわからないか、この問題を修正する方法を特定することさえ可能かどうかさえわかりません。 また、Mac OSの問題の影響を受ける人の数がわからないため、9.0.2を完全にプルすることが全体的なメリットになるかどうかを判断することはできません。 （少なくとも一部の人にとっては）9.0.1に固定することが解決策であることを理解しているので、それが最も悪い選択肢になる可能性があります。

macOS TLSの問題は、macOS <10.13でシステムPythonを使用しているすべての人に影響します

フォローアップ9.0.3の決定は@dstufftに任せなければなりません

私は@pfmooreと同じ立場にいます。

回避策は、インポートの順序を確認し、インポートするpipを他のパッケージのインポートよりも上に移動することをテストすることです（具体的には、pipをインポートする前にリクエストをインポートすると解決する場合があります）。 （これは、公式にはサポートされていないpipの内部の使用を意味することに注意してください。）

docker python3.4を使用したgitlab-ciのpip9.0.2で同じ問題が発生します：KeyError

  File "/usr/local/lib/python3.4/site-packages/pip/__init__.py", line 45, in <module>
    from pip.vcs import git, mercurial, subversion, bazaar  # noqa
  File "/usr/local/lib/python3.4/site-packages/pip/vcs/mercurial.py", line 9, in <module>
    from pip.download import path_to_url
  File "/usr/local/lib/python3.4/site-packages/pip/download.py", line 40, in <module>
    from pip._vendor import requests, six
  File "/usr/local/lib/python3.4/site-packages/pip/_vendor/requests/__init__.py", line 98, in <module>
    from . import packages
  File "/usr/local/lib/python3.4/site-packages/pip/_vendor/requests/packages.py", line 12, in <module>
    sys.modules['pip._vendor.requests.packages.' + mod] = sys.modules["pip._vendor." + mod]
KeyError: 'pip._vendor.urllib3.contrib'

参考までに、9.0.2は壊れたビルドでリリースされました。

Travis-CIリファレンス： https ：//travis-ci.org/pypa/pip/builds/354616774？utm_source = github_status＆utm_medium = notify

確かに、エラーは無関係かもしれませんが、これは「急いでリリース」のようなにおいがします...

@pfmoore

@dstufftが緊急の9.0.3リリースを作成したい場合は、それで問題ありません。 しかし、それは非常に短期的な利益にすぎず、人々がまだ輸入ピップから離れていないことに少しがっかりしています。 この問題に見舞われた人々は、まだpip 10の準備をする必要があり、単にpip._internalをインポートするように切り替えることは、私たちがサポートまたは推奨するものではないことを理解する必要があります。

これがこのリポジトリの所有者による声明だとは信じられません...あなたは文字通り「f * ckセマンティックバージョニング」と「とにかく非推奨ポリシーが必要な人」と言っただけです。

pipは、消費可能なpython apiを持っていないものとして常に文書化されていました。その時点でさえ、「かなりの年月からそう言った」カルマを好転させようとする人々に失望しています。

@RonnyPfannschmidtこれは、「100回制限速度を超えて運転することは許可されていません」と言ってから、すべてのエンジンカーをフリントストーンカーに置き換えて制限速度を強制するようなものです。もう速度制限。

あなたは、非常に悪い言葉の向きを変えることを完全に示しました-「それは壊れます」と言っていました-今それは壊れました、そして突然それが壊れることを前にあなたに言ったプロジェクトは誤りです

あなたが過ちを犯したくないので、それはただ非難するだけです

@RonnyPfannschmidt

あなたが過ちを犯したくないので、それはただ非難するだけです

つまり、pipの文書化されていない機能に依存するサードパーティのパッケージを使用することに責任があると言っています。 たぶん、私は...これらのエラーについてサードパーティのパッケージをスクリーニングし、問題またはさらに良いPRを提出する必要がありました。

しかし、現実に直面しましょう。現在、本番環境で使用されているプロジェクトはたくさんありますが、現在は壊れています。 これは道徳の問題ではなく、これが誰のせいであるかという問題でもありません。 「これを修正して、適切な警告/非推奨を提供していただけませんか」の問題です。

使用しているサードパーティのパッケージが、文書化されていない、保証されていない内部APIに依存しているために壊れた場合、そのパッケージに対してバグを報告する必要があるように思われます。

pipの部分がサードパーティの消費を目的としているか、または意図していないかの間には、簡単に見つけられる境界線があります。開発者に、本来あるべきではなかった内部APIを維持するように強制しようとすることはサポートしていません。サードパーティのパッケージによって消費されます。 私はこれをpip開発者のせいとして扱い、怒っているユーザーを彼らの道に送ることを支持しません。 誰かに腹を立てたい場合は、内部APIに依存しているパッケージを使用していることに腹を立て、メンテナに自分のコードを修正するように依頼してください。

@ anx-ckreuzberger

これがこのリポジトリの所有者による声明だとは信じられません...あなたは文字通り「f * ckセマンティックバージョニング」と「とにかく非推奨ポリシーが必要な人」と言っただけです。

私はここでの欲求不満を理解していますが、私たちが約束しなかったことについてピップメンテナーを非難する人々の意欲にますます悩まされています。

そのような告発をしたい場合は、それらをバックアップしてください

1. ユーザーコードでのpip内部APIの使用をサポートするpipメンテナーからのステートメントへのポインター。
2. pipがセマンティックバージョニングを使用する、任意のpipメンテナからのステートメントへのポインタ。

私はあなたがその証拠を見つけるとは思わない...

つまり、pipの文書化されていない機能に依存するサードパーティのパッケージを使用することに責任があると言っています。

いいえ。ただし、これらのプロジェクトではなく、pipメンテナを非難することは受け入れられません。 私たちはあなたを助けようとしていますが、それらのプロジェクトが何をするかについて責任を負うことはできません。 彼らとあなたの不満を放映します。

しかし、現実に直面しましょう。現在、本番環境で使用されているプロジェクトはたくさんありますが、現在は壊れています。 これは道徳の問題ではなく、これが誰のせいであるかという問題でもありません。 「これを修正して、適切な警告/非推奨を提供していただけませんか」の問題です。

警告を出そうとしました。 数か月前にお知らせを送信し、状況を説明するドキュメントを追加し、内部APIの使用がサポートされていないことを示すトラッカーの問題に一貫して返信しました。 非推奨を追加することは、pip自体がそれらの警告を吐き出すので、あなたが提案するほど簡単ではありません（または、pipがそれらをオフにする方法があり、他の人はそれをコピーするだけです-私たちはすでに、 pip._internalをインポートします。そうすれば、その変更でさえ彼らを止めることはできません：失望:)。

これを「修正」することに関しては、差し迫った問題に対処するために9.0.2が迅速にリリースされたことを喜んで認めますが、この問題は予期していませんでした。 たぶん、2〜3週間の寿命で9.0.3をリリースするのは合理的なことです。私自身はそうは思いませんが、それを検討すると述べました。 9.0.xリリースに関与しているのは私ではないため、個人的に同意することはできません。 私はpip10に取り組んでいます。これにより、この議論はすべて無関係になります。したがって、これがこの問題に関する私の最後の言葉である可能性があります。そのリリースに関連することに焦点を当てる必要があります。

私の個人的なアドバイス：

1. これに影響され、今すぐ回避策が必要な場合は、9.0.1に固定してください。
2. pip内部APIを使用しているために現在使用しているすべての依存関係が壊れた場合は、pip10に備えてください。 それらの依存関係をプッシュして、私たちが何ヶ月も提供してきた情報に対して行動を起こし、それが起こるだろうという事前の警告を受け取ってうれしいです。
3. pip 9.0.3が解放された場合は、ピンを取り外します。
4. どうぞ、pip 10ベータ版がリリースされたらテストし、問題があれば関係者に報告してください（サードパーティのプロジェクトが内部でpipを呼び出している場合は、私たちがpipを自分で呼び出している場合）。

Dockerコンテナ内のpip9.0.2とPython2.7.14で同じ問題が発生しました。
ただし、Dockerコンテナの外部にある開発マシンで問題を再現することはできません。
pip import（ import.pip 、 from.pip 、 \'pip 、 \"pipのgrep）を検索しましたが、何も見つかりませんでした。
私たちPloneは、setuptools setup.pyファイルに含まれているパッケージの構成を自動的に含めるメカニズムを使用しています。これは疑わしいように聞こえますが、これも__import__を使用しており、pipAFAIcanseeからのものではありません。

これは、トレースバックの関連部分です。

  File "/home/plone/.buildout/shared-eggs/zope.configuration-3.7.4-py2.7.egg/zope/configuration/xmlconfig.py", line 359, in endElementNS
    self.context.end()
  File "/home/plone/.buildout/shared-eggs/zope.configuration-3.7.4-py2.7.egg/zope/configuration/config.py", line 558, in end
    self.stack.pop().finish()
  File "/home/plone/.buildout/shared-eggs/zope.configuration-3.7.4-py2.7.egg/zope/configuration/config.py", line 706, in finish
    actions = self.handler(context, **args)
  File "/home/plone/.buildout/shared-eggs/z3c.autoinclude-0.3.7-py2.7.egg/z3c/autoinclude/zcml.py", line 51, in includeDependenciesDirective
    info = DependencyFinder(dist).includableInfo(['configure.zcml', 'meta.zcml'])
  File "/home/plone/.buildout/shared-eggs/z3c.autoinclude-0.3.7-py2.7.egg/z3c/autoinclude/dependency.py", line 26, in includableInfo
    module = resolve(dotted_name)
  File "/home/plone/.buildout/shared-eggs/zope.dottedname-4.2-py2.7.egg/zope/dottedname/resolve.py", line 39, in resolve
    found = __import__(used)
  File "/plone/buildout/lib/python2.7/site-packages/pip/__init__.py", line 45, in <module>
    from pip.vcs import git, mercurial, subversion, bazaar  # noqa
  File "/plone/buildout/lib/python2.7/site-packages/pip/vcs/mercurial.py", line 9, in <module>
    from pip.download import path_to_url
  File "/plone/buildout/lib/python2.7/site-packages/pip/download.py", line 40, in <module>
    from pip._vendor import requests, six
  File "/plone/buildout/lib/python2.7/site-packages/pip/_vendor/requests/__init__.py", line 98, in <module>
    from . import packages
  File "/plone/buildout/lib/python2.7/site-packages/pip/_vendor/requests/packages.py", line 12, in <module>
    sys.modules['pip._vendor.requests.packages.' + mod] = sys.modules["pip._vendor." + mod]
zope.configuration.xmlconfig.ZopeXMLConfigurationError: File "/plone/buildout/parts/instance/etc/site.zcml", line 15.2-15.55
    ZopeXMLConfigurationError: File "/plone/buildout/parts/instance/etc/package-includes/002-bda.aaf.site-configure.zcml", line 1.0-1.56
    ZopeXMLConfigurationError: File "/plone/buildout/src-aaf/bda.aaf.site/src/bda/aaf/site/configure.zcml", line 11.2-11.48
    ZopeXMLConfigurationError: File "/plone/buildout/src-aaf/bda.aaf.site/src/bda/aaf/site/configure-dependencies.zcml", line 10.2-10.39
    ZopeXMLConfigurationError: File "/plone/buildout/src-addons/plone.app.mosaic/src/plone/app/mosaic/configure.zcml", line 9.2-9.39
    ZopeXMLConfigurationError: File "/home/plone/.buildout/shared-eggs/plone.app.tiles-3.0.3-py2.7.egg/plone/app/tiles/configure.zcml", line 18.2-18.41
    ZopeXMLConfigurationError: File "/plone/buildout/src/plone.app.z3cform/plone/app/z3cform/configure.zcml", line 10.2-10.41
    ZopeXMLConfigurationError: File "/plone/buildout/src/plone.app.widgets/plone/app/widgets/configure.zcml", line 12.2-12.41
    ZopeXMLConfigurationError: File "/home/plone/.buildout/shared-eggs/Products.CMFPlone-5.1.0.1-py2.7.egg/Products/CMFPlone/configure.zcml", line 15.2-15.46
    ZopeXMLConfigurationError: File "/home/plone/.buildout/shared-eggs/plone.app.contenttypes-1.4.9-py2.7.egg/plone/app/contenttypes/configure.zcml", line 10.2-10.37
    KeyError: 'pip._vendor.urllib3.contrib'

私が理解している限り、pipをインポートするだけで（使用せずに）、すでに壊れています。 これは、Pythonの土地での市民の良い行動ではありません。 それの使用をサポートしない/パブリックAPIを提供しないことは、1つのことであり、別のインポートを中断するだけです。 これは、多くの自動検査コードに影響します。

このように考えてください。pipはコマンドラインユーティリティであり、ライブラリではありません。 Pythonで書かれているという事実は関係ありません。 それが問題の現実です。

@pfmoore

私はここでの欲求不満を理解していますが、私たちが約束しなかったことについてピップメンテナーを非難する人々の意欲にますます悩まされています。

このように考えてください。pipはコマンドラインユーティリティであり、ライブラリではありません。 Pythonで書かれているという事実は関係ありません。 それが問題の現実です。

肝心なのは、あなたが何を約束したかは本当に問題ではないということです。 重要なのは、あなたが何をしたか、そして結果として生じる状況は何であるかです。 多分あなたはそれをコマンドラインユーティリティとして考えました。 しかし、あなたはそれをライブラリとしてリリースしました。 それが問題の現実です。

あなたは機能Xを備えたライブラリをリリースしました。人々は機能Xを使い始めました。確かに、あなたは「みんな、機能Xを使わないでください」と言いました。 しかし、あなたはそれを機能Xでリリースし続けました。何年もの間。 そして人々はそれを使い続けました。 大小を問わず、数十、おそらく数百、数千のプロジェクトが現在それを使用しています。 突然、適切な警告なしにマイナーアップデートで削除します。

次に何が起こると思いますか？

短期的には、正当な理由がない限り、古いバージョンを固定するだけで、固定を解除することはありません。

長期的には...まあ、あなたが壊れたものすべてを修正するよりもあなたを置き換える方が費用効果が高いと判断する人の数によって異なります。

@pfmoore上記で参照したトレースバックに疑わしいものがありますか？ AFAIKの内部ピップは使用されません。 ほとんどの人がDockerコンテナ内でこの問題を抱えているのは興味深いことです。

@すべて、壊れたコードでメンテナを非難しても、問題の解決には役立ちません。

このように考えてください。pipはコマンドラインユーティリティであり、ライブラリではありません。 Pythonで書かれているという事実は関係ありません。 それが問題の現実です。

事実：何らかの理由でコードを自動検査してもインポートされた場合、インポートできません：すべてが壊れています。 これは@thetの場合に起こると思います。
結論：pipは、パッケージをインストールするグローバルまたは現在のvirtualenv / venvPython名前空間から自身を分離する必要があります。 そうすれば、それはそれを汚染せず、偶然に輸入さえも起こりません。

まず第一に、私がレポのメンテナを誤ったコードで非難した場合は申し訳ありません。 どんな非難も欲求不満からなされました、そして、もしあったとしても、IMHO 9.0.2リリースがsemverパッチリリースの定義によるものであるという事実を指摘します（ @pfmooreはpipが必ずしもsemverを使用していないことを明らかにしました-別の日の別の問題だと思います）。

@ MikeHart85

短期的には、正当な理由がない限り、古いバージョンを固定するだけで、固定を解除することはありません。
長期的には...まあ、あなたが壊れたものすべてを修正するよりもあなたを置き換える方が費用効果が高いと判断する人の数によって異なります。

かなり。 つまり、JavaScriptパッケージマネージャーを見てください：npm、bower、yarn、来週〜年〜にリリースされるものは何でも

いいえ。ただし、これらのプロジェクトではなく、pipメンテナを非難することは受け入れられません。 私たちはあなたを助けようとしていますが、それらのプロジェクトが何をするかについて責任を負うことはできません。 彼らとあなたの不満を放映します。

この問題に関する私の（私たちの？）不満は誤った方向に向けられている可能性があることを理解しています。 これがサードパーティのメンテナのせいであることをだれにも納得させるのは本当に難しいことを認めなければなりませんが。

警告を出そうとしました。 数か月前にお知らせを送信し、状況を説明するドキュメントを追加しました

これはピップ9.0.2用ですか、それともピップ10用ですか？ pip 9.0.2の場合、 Changelogにメモがあればいいと思います。 とにかく、pip 10の開発に非常に積極的に取り組み、 import pipを使用しないことについてのアナウンスを送信していただき、ありがとうございます。 がんばり続ける！

非推奨を追加することは、pip自体がそれらの警告を吐き出すので、あなたが提案するほど簡単ではありません（または、pipがそれらをオフにする方法があり、他の人はそれをコピーするだけです-私たちはすでに、 pip._internalをインポートしてください。そうすれば、その変更でさえがっかりすることはありません）。

これはそれほど難しいことではないと思います...あなたはすでに__init__.pyにこれを持っています：

if __name__ == '__main__':
    sys.exit(main())

他を追加するのはどうですか？

if __name__ == '__main__':
    sys.exit(main())
else:
    logger.warning("You are importing PIP as a Python library. This behaviour is deprecated and should no longer be used. We will break the API with version 10.0!!!111eleven Please see https://pip.readthedocs.org/some_link_where_you_explain_this.html")

編集：それについて「厳密」にしたい場合は、ここで例外を発生させ、同様のステートメントをサブモジュールに追加することもできます。

人々がこれを回避するという事実は、別のものです。 ライブラリをハックしたい場合は、いつでもリバースエンジニアリングできます。 あなたはいつでもそれを回避する方法を見つけることができます。 ただし、設計上の決定の中で、それを取り巻くすべての方法を考慮する必要はありません。

長期的には...まあ、あなたが壊れたものすべてを修正するよりもあなたを置き換える方が費用効果が高いと判断する人の数によって異なります。

私はいつもこの「脅威」を面白いと思っています。 それは、ピップのようなものに費やされる努力の量とそれが実際にどれだけの費用がかかるか（そして実際にそれに対して支払うことをいとわない人がどれほど少ないか）についての根本的な誤解を伴います。 あなたがもっとうまくやれると感じたら、ぜひそうしてください、私（そして私は他の人たちを想定しています）はそれを歓迎します。 過去数年間、そのようなことが起こることを可能にすることを明確な目標の1つとして、標準の文書化と設計に多大な努力が払われてきました。

これらのことについての視点を保つことが重要です。 あります..15未満ですか？ 20？ これがどのように彼らを壊したかについてコメントする人々（これらのメトリックには常に「氷山の一角」の問題がありますが）、一方、pip 9.0.2はすでに過去1週間で2番目に使用されたインストーラーです（それが存在しなかった日数を数えます） for）がリリースされて以来、PyPIから1700万のファイルをダウンロードしています。 最終日を見ると、PyPIで最も使用されているインストーラーとしてpip 9.0.1を追い抜く方法の80％です。

ですから、これが一部の人々にとっては問題を引き起こしたことを私は認識していますが、サポートされていないこと、またはかなりエッジケースの状況で行っているのは比較的少数の人々です。

時間を見つけることができれば、主に@thetがインポートしようとしている自動インポート機能であり、実際には使用しようとしていない場合を解決するために、9.0.3をカットしようとするかもしれません。何らかの方法でpipの内部API。 それがpipの内部APIを使用している人々の動作も解決することになった場合、私はそれらを具体的に壊すために私の邪魔をするつもりはありませんが、そうでない場合は私も修正するために私の邪魔をするつもりはありません具体的にはどちらかです。

この時点で9.0.xをリリースするのに何時間もかかることに注意してください（リリースを行うには多少の手間がかかるほどmasterで分岐しています）、デバッグに必要な時間はカウントされません実際の問題を修正します。 これが発生する可能性を高めたい場合は、そのデバッグと修正を行い、パッチ（または独自のフォークの9.0.2タグからの分岐）を提供することが最善の方法です。

まず第一に、私がレポのメンテナを誤ったコードで非難した場合は申し訳ありません。 どんな告発も欲求不満からなされました

ありがとう。 ここは欲求不満が高く、理解しています。

他を追加するのはどうですか？

良い考えです-少し前にこれについて考えていたらよかったのにと思います。 もちろん、内部名前空間はpip 10で再編成されるため、今は意味がありません。手遅れです。 私は確かに将来のためにこのトリックを覚えています。

これはピップ9.0.2用ですか、それともピップ10用ですか？

10.0の場合。 9.0.2をリリースする当初の意図はありませんでした。TLSの変更が有効になったときにMacOSのユーザーがPyPIへのすべてのアクセスを失うことがないように、緊急リリースとしてのみリリースしました。

@dstufftはここでより完全に応答したので、これは今のところ解決される可能性が高いと思います。

私はいつもこの「脅威」を面白いと思っています。

それはまったく脅威ではありません、それがそのように出くわしたならば、謝罪します。

これは、ソフトウェアの世界で非常に頻繁に発生することについての観察です。 人々はあなたの約束や意図に従わない。 人々はあなたが提供する製品を扱います。 あなたの製品が多くの人々に依存するようになる機能を持っているなら、あなたはもはや彼らの足元からそれを引っ張るだけではいけません。 そうした場合、彼らはあなたの製品が壊れていると見なし始めます。 あなたが提供する唯一の説明が「まあ、とにかくこれを約束したことはありません」である場合、彼らはあなたが彼らの懸念を責任として認めたがらないことに気づき始めます。

これが多ければ多いほど、代替案に対する欲求と需要は大きくなります。 確かに、人々はそれにかかる作業量を過小評価しています。 しかし、それは彼らをより多く、より少なくではなく、1つに取り組み始める可能性を高めるだけです。 そのボールが転がると、それはそれ自身の寿命を持ちます。

代替案は必ずしも良いことではありません。 彼らは物事を乱雑にする傾向があります。 個人的には、単一のパッケージマネージャーが好きです。 全てにおいて。 しかし、私はPython用の単一のパッケージマネージャーを選びます。

意図的であろうとなかろうと、機能が壊れたと人々が報告するときは、「これはずっとサポートされていなかった」という懸念を却下するのではなく、なぜそれを壊さなければならなかったのか、なぜそれを維持できなかったのかを簡単に説明することを検討してください。

ねえ@dstufft 、チャイムをしてくれてありがとう。このスレッドはかなり熱くなっています！

まずはお仕事ありがとうございます！ メンテナンスは終わりのない、ありがたい仕事であることを私は知っています、そしてあなたがpipのように大きくて人気のあるプロジェクトを管理するときだけ、それは悪化すると思います！

さて、当面の問題について：これまでに20人の_maintainers_がこの問題を報告しましたが、それはすでに数千人の_people_に影響を及ぼしていることを私は知っています-影響を受けるプロジェクトのいくつかはそれ自体で大規模です：Anaconda、OpenStack、SpaCy、Zappa、そして何万人ものユーザー。 私たちのSlackチャンネルはこれについての議論で溢れています。 （文字通り、これを入力しているときに、新しい問題が発生しました。）

明らかに、プログラムで環境を検査する機能を必要とする多くの重要なPythonプロジェクトがあります。 これは、実行できるようにする必要がある完全に合理的なことです。 さらに、ドキュメントはこれを行うことに対して警告することはありません-そしてそれでも警告しません！ （このリポジトリのREADMEからドキュメントのリンクをクリックしてください！）

これまでの状況は次のとおりだと思います。

• バージョン文字列の形式を考えると、pipメンテナはセマンティックバージョニングに従っていると私たちは皆信じていました
• ピップメンテナは、大幅な変更を導入した「パッチ」をリリースしました
• この変更は発表も文書化もされていませんでした-そして私は、予期せぬ、意図しないものだと思います
• 今、 import pipを呼び出すだけで、プログラムがすぐに壊れます。これは、開発者にとって非常に敵対的です。
• これは、Pythonエコシステム全体で大きな頭痛の種を引き起こしています
• ドキュメントは、プログラムpipを使用することに対して警告しません（そして_まだ_しません-このリポジトリのREADMEのドキュメントリンクをクリックします）。
• import pipがPATCHアップデートでこの損害を引き起こすという発表はありませんでした-その発表は_まだリリースされていない_バージョンに対して行われました。
• この変更は、変更ログにも記載されていませんでした
• pipやpip開発者を置き換えたくありません！ 私たちはあなたを愛してます！
• ..しかし、この種のことが二度と起こらないようにしたいと思います。
• ..だから私たちはsemverが続くことを望んでいます！
• この大きな重大な変更を元に戻す別のPATCHが本当に欲しいです！

pip> = 10.0.0の世界で環境をプログラムで検査する方法の必要性は別の議論のトピックですが、当面の問題の事実は、pipでプログラムでpipを使用するべきではないと言われたことがないということです。 <= 9の世界であり、予告なしに大規模な変更がありました。何千人もの人々に悪影響を及ぼしているため、それが逆転することを本当に望んでいます。

再度、感謝します、
リッチ

まず第一に：プロジェクト内での彼らの努力と洞察にピップメンテナーで感謝します。 これは他の人が問題を理解するのに本当に役立つと思います（それについての要約ブログ記事を書く価値があるかもしれませんが）。

@dstufft

これらのことについての視点を保つことが重要です。 あります..15未満ですか？ 20？ これがどのように彼らを壊したかについてコメントする人々（これらのメトリックには常に「氷山の一角」の問題がありますが）、一方、pip 9.0.2はすでに過去1週間で2番目に使用されたインストーラーです（それが存在しなかった日数を数えます） for）がリリースされて以来、PyPIから1700万のファイルをダウンロードしています。 最終日を見ると、PyPIで最も使用されているインストーラーとしてpip 9.0.1を追い抜く方法の80％です。

継続的インテグレーション/デリバリーシステムからのすべての自動化されたpip install pip --upgradeコマンドによってメトリックが大きく偏っていると確信しています（キャッシュを使用する必要があるため、常にpypiからパッケージを再インストールする必要はありません。同時に、 import pipを実行するべきではありません...これがITの世界の仕組みです）。

15人未満がこれについて不満を言っているという事実は、2つのことを示しているはずです：

1. まだ多くの人が9.0.2（本番環境）を使用しているとは思いませんが、まだこの問題をデバッグしようとしている人がいて、解決されるまで（または永久に）代わりにpip9.0.1を使用して「一時的に」修正します。 。）-また、何かがまだ機能していないことに気付いていない人もいるかもしれません...
2. リリースから2日以内にすでにそれについて話している人々がいます。 より多くの人がこの問題を経験するでしょう。 2週間待つと、100人の人がそれについて不満を言うことになります（たとえば、スプリントを終了してQA /ステージングに展開したとき）。 この時点では、この変更によって何人の人が影響を受けるかは本当にわかりません。

とにかく、この問題について話したり議論したりすることで、内部APIに依存してはならない理由を示す良い例が得られます。サードパーティのパッケージメンテナが、ここで話し合ったことを理由にプロジェクトを更新することを願っています。

明らかに、プログラムで環境を検査する機能を必要とする多くの重要なPythonプロジェクトがあります。 これは、実行できるようにする必要がある完全に合理的なことです。 さらに、ドキュメントはこれを行うことに対して警告することはありません-そしてそれでも警告しません！ （このリポジトリのREADMEからドキュメントのリンクをクリックしてください！）

なぜこれに対して警告しなければならないのか私にはわかりません。 コマンドラインツール以外のものとしてのpipの使用は、完全に文書化されていません。 ドキュメントを検索すると、pipのインポートへの参照がまったく表示されません。 Chromeで使用されている.soにリンクしていて、ABIの互換性が失われているため、不平を言っているようなものです。

SemVerの通常の解釈は、ドキュメント化されていない内部ではなく、サポートされているパブリックインターフェイス（この場合はCLI）に適用されるというものです。 内部を使用する人は、任意の変更の対象となるため、とにかくpipバージョンを固定する必要があります。

本当に逆転するものは何もありません。 近い将来、macOSのかなりの数のユーザーがPyPIにアクセスできなくなるのを防ぐためのバックポート修正には、サポートされていない条件下でのみ表現されるように見える9.0.xコードベースに適用された場合のバグがあります。 前進する唯一の道は、9.0.xシリーズのそのバグを解決するために追加の作業を行うことです。 私が言ったように、私が時間を見つけることができれば私はそれをやろうとします、あなたがそれが起こる可能性を高めたいなら、それからパッチを提供してください。

pipで実行できる可能性があるがサポートされていないことの完全なリストを提供することは不可能であるため、ドキュメントはそれに対して警告していません。 代わりに、サポートされているものを文書化するというかなり一般的なアプローチに依存しており、文書化されていないものはすべてサポートされていないと見なす必要があります（文書化されていないものに依存したい場合は、文書化してサポートするように求める問題が発生します）。

長期的には、私たちがsemverであるかどうかについての混乱を（うまくいけば）取り除くために、日付ベースのリリーススキームに移行する可能性があります。

私のiPhoneから送信された

2018年3月20日午前11:02に、RichJonesの[email protected]は次のように書いています。

ねえ@dstufft 、チャイムをしてくれてありがとう。このスレッドはかなり熱くなっています！

まずはお仕事ありがとうございます！ メンテナンスは終わりのない、ありがたい仕事であることを私は知っています、そしてあなたがピップのように大きくて人気のあるプロジェクトを管理するときだけそれは悪化すると思います！

さて、目前の問題について：これまでに20人のメンテナがこの問題を報告していますが、それはすでに何千人もの人々に影響を及ぼしていることを私は知っています-影響を受けるプロジェクトのいくつかはそれ自体で大規模です：Anaconda、OpenStack、SpaCy、Zappa、そして何万人ものユーザー。 私たちのSlackチャンネルはこれについての議論で溢れています。 （文字通り、これを入力しているときに、新しい問題が発生しました。）

明らかに、プログラムで環境を検査する機能を必要とする多くの重要なPythonプロジェクトがあります。 これは、実行できるようにする必要がある完全に合理的なことです。 さらに、ドキュメントはこれを行うことに対して警告することはありません-そしてそれでも警告しません！

これまでの状況は次のとおりだと思います。

バージョン文字列の形式を考えると、pipメンテナはセマンティックバージョニングに従っていると私たちは皆信じていました
ピップメンテナは、大幅な変更を導入した「パッチ」をリリースしました
この変更は発表も文書化もされていませんでした-そして私は、予期せぬ、意図しないものだと思います
現在、import pipを呼び出すだけで、開発者にとって非常に敵対的なプログラムがすぐに中断されます。
これは、Pythonエコシステム全体で大きな頭痛の種を引き起こしています
ドキュメントは、プログラムでpipを使用することに対して警告していません（そして、まだしていません-このリポジトリのREADMEのドキュメントリンクをクリックしてください）。
import pipがPATCHアップデートでこの損傷を引き起こすという発表はありませんでした-その発表は、まだリリースされていないバージョンに対して行われました。
この変更は、変更ログにも記載されていませんでした
pipやpip開発者を置き換えたくありません！ 私たちはあなたを愛してます！
..しかし、この種のことが二度と起こらないようにしたいと思います。
..だから私たちはsemverが続くことを望んでいます！
この大きな重大な変更を元に戻す別のパッチが本当に本当に欲しいです！
pip> = 10.0.0の世界で環境をプログラムで検査する方法の必要性は別の議論のトピックですが、当面の問題の事実は、pipでプログラムでpipを使用するべきではないと言われたことがないということです。 <= 9の世界であり、予告なしに大規模な変更がありました。何千人もの人々に悪影響を及ぼしているため、それが逆転することを本当に望んでいます。

再度、感謝します、
リッチ

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示するか、スレッドをミュートしてください。

@Miserlou

バージョン文字列の形式を考えると、pipメンテナはセマンティックバージョニングに従っていると私たちは皆信じていました

semverに強く反対している人として、この混乱をなくすために私のバージョン文字列をどの形式にするべきか教えていただけますか？ 「3つの点線の数字」は、私にとって「厳密にsemverに従う」ことを意味するものではないので、この仮定は驚きです。

このコメントへの応答：pipがsemverに準拠しているかどうか、または準拠することを約束しているかどうかにかかわらず、 major.minor.microバージョン管理スキームの使用は、マイクロリリースに関する何らかの制限の暗黙の約束を依然として実行します。 ~= 9.0.1のような互換性のあるリリースピンでは、下位互換性の予期しない中断からユーザーを保護するのに十分でない場合、残っている唯一の安全な代替手段は、プレーンバージョンマッチングです。 バージョンマッチング以外のものをサポートする意図がない場合、pipは、単調に増加するコンポーネントが1つしかないChromeスタイルのバージョンスキームに切り替えることもできます。

編集： @dstufftは、日付ベースのバージョンを採用することで、この方向への移行をすでに提案していることがわかります。 これは、今回の事件による二次的被害の不幸な部分だと思います。

そうです、ボランティア主導のソフトウェアプロジェクトのユーザーとして、ユーザーと保守者の関係の性質に対する期待と期待のバランスをとる必要があります。 また、このリリースがimport pipを突然失敗させることを意図していないことも明らかです。 一方で、マイクロリリースでこの種のリグレッションが発生することに人々が不満を感じるのは合理的だと思います。問題を修正する9.0.3バージョンをリリースすることは、合理的な救済策のようです。

余談ですが、次の手順で、virtualenv（2または3、それは問題ではありません）でこれを再現できます。

virtualenv -p python3 /tmp/pip
/tmp/pip/bin/pip install -e path/to/clone/of/pip/9.0.2
/tmp/pip/bin/pip install requests
/tmp/pip/bin/python

次に、Pythonシェル内で：

>>> import requests
>>> import pip

リクエストがまだインポートされていない場合、 import pip成功します。

下位互換性の予期しない中断

import pipが、下位互換性の約束に該当する安定したAPIであると文書化されている場所を教えてください。 私たちはその使用を強くサポートしていないので、そのようなドキュメントを削除することを確認したいと思います。

サポートされていない、テストされていない使用であっても、絶対に損益分岐点がないという意見がない限り。 その場合、おそらく==を固定する必要があります。これは、その時点で何を使用しているのかが完全にわからず、すべての変更が誰かにとって重大な変更になる可能性があるためです（必須のxkcd ）。

pipはPythonのパッケージマネージャーです。 Pythonはプログラミング言語です。 人々はプログラムで環境を検査する必要があります。 1 + 1 = 2。

これが正しい方法であると人々が考えるのは完全に合理的でした。 ドキュメントには、これを行うように_しない_と書かれているものはありませんでした。 念のため、これと同じ結論に達した70万を超えるアプリケーションがあります。 また、他に方法はありません。

ReadTheDocsに文書化されていないからといって、それが禁止されているわけではありません。私たちは皆、この方法でコードを提供するだけのプロジェクトに毎日遭遇し、使用しています。

どちらかといえば、 pipでさえコマンドラインインターフェイスを持っているという事実は、すでにPythonクライアントを持っているので、ライブラリとして使用できることを示す良い兆候のようです。

さらに、慣例のように_で名前空間が設定されたプライベートAPIや、特定のパブリックメソッドについて話しているのではなく、この壊滅的な失敗を引き起こす_importを呼び出すだけ_について話しているだけです。

ドキュメントには、これを行わないようにと言っているものはありませんでした。

https://pip.pypa.io/en/latest/user_guide/#using -pip-from-your-program

_this very repo_の[Docs]リンクをクリックしても、そのページにはアクセスできません。 誰も最新のものを参照していません。 ドキュメントへの独自のリンクは、最新のものにはリンクしていません。 そのページにアクセスする方法はありません。 すべてが安定しますが、そのセクションは含まれていません。

@Miserlouメモは、Pythonで実装されており、それらの内部がインポート可能であるという理由だけで、コマンドラインツールの内部をインポートする必要があるとどういうわけか考えている人にとっては親切だと思います。

pipのパブリックインターフェイスの解釈は、私、開発者、およびpipをCLIプログラムと考えるほとんどの人とは異なると思いますが、これの実際の害は何ですか？ pip != 9.0.2を固定するだけで、それで終わりです。

サポートされているパブリックAPIの一部であるかどうかについて、この時点で私たち全員が同じページにいることは明らかです。また、何とかしてすべての人にさかのぼって通知するために今できることは何もありません。

正直なところ、pipのメンテナは、時間が許せばこの問題を修正しようとするとすでに述べていますが、スピードを上げるためにプルリクエストを提出することをお勧めします。

今のところ私たちにできることは、サードパーティのライブラリにこの問題を認識させ、この問題を指摘することだけだと思います。 長期的なサードパーティライブラリは、とにかくこの問題を修正する必要があります。できれば、 import pipではなく、コマンドラインから（サブプロセスまたは同様のPythonコマンドを使用して）pipを呼び出す方法で修正する必要があります。

私は、この議論が生産的である可能性は低く、実際に言うべきことは何もないと信じています。 有る：

• 問題の適切な説明。
• 誰かがそれに遭遇した場合に採用できる可能性のある回避策。
• 下位互換性ガイドラインに従って、これを重大な変更と見なさない理由。
• 私がそれを修正する時間を見つけようとするという声明（それについての約束はありませんが）。
• これに影響を受けた誰かが修正で9.0.3が存在する可能性を高めたい場合に実行できる、行動の呼びかけ。

この時点での議論は、関係者全員をさらに苛立たせることを除いて、本当の目的には役立たないので、私は今のところこの問題からお辞儀をしています。 この問題は、10.0または9.0.3のリリース時にクローズされます。 誰かが召喚状に力を入れている場合は、プルリクエストを開くか、この問題に関する差分を送信してください。

このdo-not-import-pipのマントラをより見やすくするために、名前空間の名前を「_pip」に変更するのはどうでしょうか。 これは、全体が名前レベルで公開されていないことを示しています。
また、アンダースコアで始まるものを見ないように自動検査コードに指示する方が簡単です。 まあ、後者も関与検査コードの変更が必要になります。 しかし、少なくとも、ブラックリストを管理せずに（慣例により）自動化する機会があります。

さて、最後に誓います。pip10は、関連するすべてのコードをすでにpip._internalに移動しました（サポートされているpython -m pipが破損するため、 _pipは使用しませんでした）。

https://github.com/pypa/pip/pull/5100がこれを解決するかどうかを誰かが確認できますか？

＃5100が間違っていると思いますが、代わりにhttps://github.com/pypa/pip/pull/5101を確認してください。

@dstufft確認できましたが、＃5101の修正で問題が解決しました。

これに対処するために時間を割いてくれてありがとう@dstufft 。 私はAnacondaチームと協力してこの問題を伝え、pipのインポートから離れるのを支援します。

このスレッドの記録では、＃5101も私の問題を解決しました。

同上、＃5101を使用すると、インポートをツール内で機能させることができます。 警告エンプター：パッチを適用したピップもツールも広範囲にテストしていません。

これは9.0.3で修正されるはずです。

人生でimport pipを書いたことはないが、書いたパッケージの消費者だった人からの迅速な解決に感謝します。 このスレッドを読んだ後、多くのアプリが無意識のうちにベストプラクティスに反して、pipをインポートしたように聞こえます。また、多くの開発者とユーザーがv9.0.2とv10の影響を受ける可能性があります。

物事をスムーズにするために、2番目/ 3番目/ N番目に適切な非推奨の警告が追加されています。 多分pypi.python.orgの投稿ですか？

やったー！ これをありがとう！

また、非推奨の警告、さらに重要なことに、pip10の世界でPython環境をプログラムで検査する方法についての適切な指示が大好きです。 700,000を超えるアプリケーションがこのバグの影響を受けたことを考えると、明らかにその必要性があります。

pip list --format=json ？

まず、pipの人々に貢献してくれてありがとうございます。これは、いくつかのユーザーフレンドリーなオプションと引数を使用して、私のすべてのユースケースを完全にカバーしています。

この「驚くほど広く採用され、有用な未定義動作」のために、gitのlibgit2としてpiplibを作成する必要がありますか？ libgit2はgitとコードを共有しておらず、gitの他のグループによって維持されていることに注意してください。 そして、それはgitエコシステムに適しています。 たぶん、piplibは、私たちが予期していなかったいくつかの興味深いユースケースをカバーするでしょう。

同様の話があります： https ：//public-inbox.org/git/1267957655.3759.29.camel@mattotaupa/T/

@drunkwcodesあなたが提案したものは、pipドキュメントに記載されている既存のパッケージ、 packaging 、 setuptools 、およびdistlibにすでに実装されていると思います。 このスレッドからわかる限り、機能のギャップに問題はありませんが、すべてのモジュールをインポートして検査し、インポートの失敗を致命的なエラーとして扱うツールに問題がある人もいます。

このようなツールは、importステートメントをtry / exceptionブロックでラップすることでこの問題を回避できるように思われますが、これも設定する前例としては疑わしいようです。 ただし、pip 9.0.3のリリースを考えると、pip 10で問題が再び発生しない限り、インポートの問題について議論する時間はおそらく価値がないと思います。とにかく、メンテナが邪魔にならない限り、 import pipが失敗するか、そのような失敗を修正するパッチを簡単に拒否する場合、立ち向かう共通の根拠があります。

@sruggier記載されているパッケージはすべて優れており、 WheelFile.install（）にもさらにプロモーションが必要です。 しかし、提供されるワンストップサービスpip.main()は、上記のすべてでかけがえのないものです。 それでも試す価値はあります。

最も重要なことは、これらのニーズが別のプロジェクトによって保持され、pip10が追加の保証なしでスムーズに到着することを願っています。 非推奨とコードベースの最小化は、メジャーリリースの要点です。

永続的なインフラストラクチャ「ソフトウェア」の具体的な実装の詳細はばかげています。 文書化された虐待事件でメンテナを判断し、ピップの輪を抑えることはできません。

pipをlibとして使用することを主張する場合は、多くの仮定を再検討する必要があります。

@drunkwcodes明確にするために、 pip.main()は、置き換えるのが最も簡単な使用法です。単にsubprocess.run([sys.executable, '-m', 'pip', <rest of args>])を使用する必要があります。

また、 WheelFile.install()が宣伝されない理由は、wheelプロジェクトがユーザーに表示されるAPIを提供しないと述べているためです。最初はpipドキュメントでwheelについて言及しましたが、リクエストに応じて削除しました。 ホイールPEPは、ホイールの取り付け方法についてはかなり明確ですが、サードパーティのモジュールに実装するのは難しくありません。

皆さんがピップで行っている作業に感謝します。それは簡単ではないことを知っています。 しかし、記録のために：

人々がまだ輸入ピップから離れていないことに少しがっかりしています。 この問題に見舞われた人々は、まだピップ10の準備をする必要があります

spaCyはimport pipから移動しました。 しかし、一部の人々はまだspaCy 1を使用しています。これはpipをインポートしました---そして明らかな理由で、pipをパッチリリースにピン留めしませんでした。 変更がv10で行われた場合、古いバージョンは影響を受けませんでした。 これに対処するための修正プログラムを発行しました。

pip10の世界でPython環境をプログラムで検査する方法に関する適切な指示

distlibに対するPyPAの立場は何ですか？ Pipは明らかにある程度の容量でそれを使用していますが、distlibが非推奨と称するパッケージングも使用しています。

公式の立場がない場合は、少なくともpipのコアメンテナからの現在の考えや意見をいただければ幸いです。 このトピックに関する関連するディスカッションが他の場所にある場合は、他のディスカッションへの単純なポインタで十分です。

distlibがパッケージングを廃止していることに気づいていません。 「distutils2 / packages」と記載されていますが、distutils2は別のものでした。

私の個人的な見解では、distlibとpackagingはどちらも完全に合理的な使用方法です。 自分で評価して、他の依存関係と同じように、ニーズを満たしていることを確認する必要があります。

たぶん、非難することは言葉が強すぎる。 私の現在の理解の源：

https://distlib.readthedocs.io/en/latest/overview.html#distlib -evolved-out-of-packaging

ああ、それは別の「パッケージング」です-distutilsを置き換えることを目的とした提案されたstdlibモジュールでした。 これは、PyPI packagingプロジェクトとは完全に異なります。 その区別をもう少し明確にするために、distlibプロジェクトに依頼する価値があるかもしれません。

その区別をもう少し明確にするために、distlibプロジェクトに依頼する価値があるかもしれません。

すでにそれを行っています:)参照： https ：//bitbucket.org/pypa/distlib/issues/100/clarify-project-positioning-and-status

このスレッドは、閉じられた後、最近のアクティビティがないため、自動的にロックされています。 関連するバグについては、新しい問題を開いてください。