Pip: 新しいリゾルバー：ロールアウト、フィードバックループ、開発フロー

どのように計画しているかはわかりませんが、1つのコメントとして、新しいコードと現在のコードの間で可能な限りコードを共有し、作業中に現在のコードをリファクタリングすることをお勧めします。新しいコードパスと現在のコードパスの間でより多くの共有を許可します。

1つの理由は、より多くのコードを共有している場合、両方の状態でその共有コードを実行することになり、対処すべき行動の多くの潜在的な違い。

これには、ユーザーにCTAを試してもらい、フィードバックを提供するように依頼することが含まれます。

新機能に関する事前のフィードバックを得た私たちの実績はかなり悪いものでした。 私たちはベータリリースを試し、問題が発生した場合に使用できる「オプトアウト」フラグを備えた新機能をリリースしました。

私の個人的な感想は、「利用可能にしてフィードバックを求める」というのは、これまでに試したことの興味深いバリエーションですが、最終的にはそれほど大きな違いはありません。 自動ビルドパイプラインでデフォルトオプションを使用して最新のpipを使用し、新しいpipバージョンに移行する前にテストしない人が多すぎます（これはPEP 517で確認されました）。

PSFの助成金を取得して、この機能の大規模な「現実世界」のテスト演習を行うためのリソースを取得することはできますか、それとも（さらに良いことに）テストインフラストラクチャを開発することはできますか？ このようなプロジェクトには、ワークフローと構成を通知するプロジェクトの呼び出しが含まれる可能性があります。これにより、新しいpipバージョンがそれらを壊さないことを確認するテストパスを設定できます。 または、助成金を使用して、新しい機能のベータテスターを取得するというコミュニケーションの側面を経験してもらい、より優れたユーザーテストプログラムを設定するのに役立てることもできますか？

git / GitHubに関しては、これはおそらくpip内での最初の「実験的」機能の実装です。

それが何を意味するのか100％わかりません。 確かに過去には、「古い方法」がまだ存在している間に追加された新機能がありました。 「デフォルトでオフにして、試してみることができる」という傾向はありませんが、それは主に、フィードバックを得る良い方法が見つからなかったためです（上記を参照）。

私はこの1つの投稿を書くのに約60分（re-re-re-re-re-）を費やしたので、今度はニューヨークの場所を見ていきます！ 私からの迅速な応答が表示されない場合、それは私が観光モードになっているためです。

新しいコードと現在のコードの間で可能な限りコードを共有し、作業中に現在のコードをリファクタリングして、新しいコードパスと現在のコードパスの間でより多くの共有を可能にすることをお勧めします。

間違いなく！ これが、私が＃5051をこれよりも優先する理由の80％です。ビルドロジックに蓄積した技術的負債の多くを返済して、再利用しやすくするつもりです（すべて？）。 コードの束は：fire：である必要があり、残りは間違いなく合理的な範囲で再利用する必要があることに同意します。

それがあなたの言いたいことなら、私たちはそれらを「デフォルトでオフにし、それらを試してみることができるようにする」ままにする傾向はありませんでした

うん、確かに。 ここで開発フローもほのめかしています-IMOは、空のインフラストラクチャ（後続のPRで具体化されるraise NotImplementedError()のメソッドの束を持つクラス）をマージしても問題ありません。 「実験的/アルファ」として明示的に示されているフラグの背後でのみ使用されている限り、すべてのケース（中途半端な実装）をmasterブランチにカバーします。

再：フィードバック

私は若く、愚かで楽観的です。このロールアウトをオプトインにして、積極的なフィードバックを得て、それに基づいて行動したいと思っています。 「プロアクティブ」とは、アルファ/ベータ機能を試して、それがどのようなものかをお知らせするために、少し時間を割いて喜んでいる人々を意味します。 私たちが十分な騒ぎを起こし、戦略的に人々をターゲットにして手を差し伸べれば、詳細/問題を解決するのに役立つ新しい機能を試す時間とエネルギーを持っている人々から良い「積極的な」フィードバックを得ることができると思います。

最近の「主要な」変更を見ると、受け取ったフィードバックのほとんどは反応的だったと思います。ワークフローが壊れたときにワークフローの問題に気付いたユーザーから、それについて私たちに連絡してください。 彼らの多くは、新しい機能の詳細を明らかにするのを手伝う時間がなかったかもしれません。それは多くの摩擦を引き起こします。 これらはまた、私たちの「解約予算」[1]の多くを犠牲にしましたが、Python Packagingはとにかくあまり残っていないので、これ以上費やしたくありません[2]。

FWIW、私はPyPIの立ち上げからいくつかのアイデアを借りる予定です。たとえば、かなり目に見える場所（つまり、私の個人的なブログではない）でブログを投稿したり、ポッドキャストやタイミングの良い実用的なメールを送信したりします。 /経由で通信するための手段。 私がPyConで学んだ（多くの！）ことの1つは、私たちが使用していないチャネルがあるということでした。これは情報を広めるのに役立ちますが、広めるものがあるかどうかを確認しようとはしません。

明確にするために、私はPEP 517で採用した展開アプローチに批判していません。特に、私たち全員がボランティアであるという事実を考えると、うまくいっていると思います。 私は、私たちが抱えていた問題を回避するために、私たちが何を学ぶことができ、実用的な項目を見つけようとしています。 これらの項目のほとんどは、メンテナからのより多くの作業を伴います。私がこれについて考えることにずっと時間を費やしている主な理由は、これを変更管理の方法の楽しい学習演習と見なしているためです。

再：助成金

はい、私たちは間違いなく助成金/経験豊富な人を使って、コミュニケーション、展開、インフラストラクチャのテストを理解するのを手伝うことができると思います。 しかし、それは私が保証できるより安定した時間/週の数を持っていないので、助成金を書く仕事をし、私が今作ることができるよりも具体的な計画を考え出す誰かを必要とします。

FWIW、PSFは、ChangesetConsultingとのPyPA /パッケージング関連のコミュニケーションを理解するための継続的な契約を結んでいます。

会話にさらに多くの人を追加する計画状態のかなり早い段階であるため、私は意図的に人に@メンションをしていません。

脚注：

1. @ pganssleが使用した本当に素晴らしい用語で、私は間違いなく使用します。
2. そのため、「pip-cli」パッケージの実装が提案されており、ロールアウトをどのように表示するかについて合理的なコンセンサスが得られているにもかかわらず、＃3164をバックバーナーに配置しました。

私は若く、愚かで楽観的です

:-)そして、私は時々年を取りすぎて、疲れていて、冷笑的です。 あなたの哲学に行きましょう、それははるかに良く聞こえます:-)

間違いなく！ これが、私が＃5051をこれよりも優先する理由の80％です。ビルドロジックに蓄積した技術的負債の多くを返済して、再利用しやすくするつもりです（すべて？）。

素晴らしい！

今IRCから：

[sumanah] pradyunsg：リゾルバーでより多くの作業をより速く行うために、pip＆packagesコミュニティができることはありますか？
...。
[pradyunsg]実際、現時点では、 https：//github.com/pypa/pip/issues/6536での入力は、作業へのアプローチ方法や人々からのフィードバックの取得方法などを理解するのに役立つでしょう。
...。
[sumanah] pradyunsg：re：新しいリゾルバー：ロールアウト、フィードバックループ、開発フロー＃6536-必要な入力は次のようなものです：フィーチャーフラグアプローチは良いアイデアですか？ pip GitHubの問題以外のメカニズムを介してフィードバックを取得することは良い考えですか？ 助成金などを取得して、実際の手動テストと堅牢なテストインフラストラクチャを構築したり、プロアクティブな通信を行ったりすることをお勧めしますか？
..。
[pradyunsg]うん-私が提案しているアイデアが良いかどうか。 また、展開とフィードバックをよりスムーズにするのに役立つ可能性のある追加のアイデア/アプローチ/考えは素晴らしいでしょう。

そう：

機能フラグアプローチは良い考えですか？ はい。

pip GitHubの問題以外のメカニズムを介してフィードバックを取得することは良い考えですか？ はい。 専門性の低いユーザーからの構造化されていないバグレポートを受け入れる自動化された方法を見つける必要があります。

より堅牢なテストインフラストラクチャが役立ちますか？ はい、たくさんあります。これは私たちのスポンサーが私たちを助けることができるかもしれない場所です。

チェンジセット（私）は、PyPAの調整/コミュニケーションを支援するPSFとの既存の契約の下で、より体系的な実世界の手動テストを取得するためのプロアクティブなコミュニケーションを支援することができますか？ このロールアウトを開始するまでに契約に何時間も残っていると仮定すると、はい。

ユーザーエクスペリエンス、コミュニケーション/宣伝、およびテストについてより多くの支援を得るために、助成金などを取得することは良い考えですか？ はい。 PSF助成金は、 NLNet助成金（ 30,000ユーロ未満の要求に対する）、科学助成金に不可欠なChan Zuckerbergの必須オープンソースソフトウェア、およびMozillaのMOSSと同様に、潜在的に興味深いものになるでしょう。 パッケージングWGは記録の申請者になることができます。 @pradyunsgまたは@pfmooreが「おもしろそうですね」とうなずきたい場合は、WGでそれらの可能性の調査を開始できます。

@pradyunsgまたは@pfmooreが「おもしろそうですね」とうなずきたい場合は、

それは間違いなく私には面白そうですね:-)

@pradyunsgまたは@pfmooreは、「おもしろそうですね」とうなずきたい

_nods_ええそれは面白そうですね

より堅牢なテストインフラストラクチャが役立ちますか？ はい、たくさんあります。これは私たちのスポンサーが私たちを助けることができるかもしれない場所です。

@brainwaneここにも関連するのはhttps://github.com/pypa/integration-testです。 これを設定することは、資金調達のもう1つの潜在的な領域だと思います。これをhttps://wiki.python.org/psf/Fundable%20Packaging%20Improvementsに追加する必要があります。

わかった！ 私はPSFやChanZuckerberg Initiativeの人々と、Packaging WorkingGroupを介したCZI助成金の申請について話し始めました。 新しいpipリゾルバーが重要である理由について、Fundable Packaging Improvementsページにいくつかの詳細を追加し、そのリストにintegration-testプロジェクトを追加しました。 そして、私は、複雑なコマンドラインのパッケージ配布/インストールツールチェーンを調査し、ユーザーと話し合って、何が起こっているのか、何が起こるべきかについてのメンタルモデルを理解する能力を持つユーザーエクスペリエンスの専門家の名前を集め始めました。 、およびメンテナにアドバイスします。

MOSS、CZI、またはNLNETからの助成金でお金を稼ぐなら、私たちはお金を稼ぐと思います...早くても10月でしょう。 PSFからの直接の助成金はおそらくもっと速いでしょうが、 「私たちの現在の焦点は、Pythonワークショップ、会議（特に財政援助のため）、およびPythonの多様性/包括性の取り組みです。」

考慮事項の1つは、Brettと運営評議会の関係者が、プロジェクト管理への投資について話し、これらのプロジェクト（triage、プロジェクト管理など）を管理するための何らかの有償リソースを検討していることを知っています。彼らはPSFと話し合っています。直接。 長期的な持続可能性についての話を聞いたので、彼らが何をしているのか、何を考えているのかを調べてみる価値があるかもしれません。

機能フラグは優れており、オプトインも優れています。 検討する可能性のあることの1つは、ユーザーにリゾルバーを試すようにランダムに促すことができるかどうかです（たとえば、非常にまれで、一度にインストールする場合のみ、つまり、ユーザーにリゾルバーを永続的にオンにする必要はありません）。 次に、リゾルバーがどのように役立ったかを示すことができます（たとえば、リゾルバーはそれらに対して何をしましたか？どのような競合が発生して解決しましたか？）

たとえば、javascriptやrustから来た人も、ある種のロックファイルを期待するので、それは考慮すべきことかもしれません...

飛び込んで申し訳ありませんが、これが前進するのを見てうれしいです！

私の個人的な感想は、「利用可能にしてフィードバックを求める」というのは、これまでに試したことの興味深いバリエーションですが、最終的にはそれほど大きな違いはありません。 自動ビルドパイプラインでデフォルトオプションを使用して最新のpipを使用し、新しいpipバージョンに移行する前にテストしない人が多すぎます（これはPEP 517で確認されました）。

まさにこの理由でいくつかのPEP517の問題に悩まされた人の一人として、私は実際に物事をテストするオプトインの方法を見たいと思っています。 しかし、 --no-use-pep517フラグの問題が発生した後、すべてのpythonパッケージニュースソースを購読したので、私はこの種のことしか知りません。 私が言っているのは、この種のニュースを広めるのは難しいことであり、おそらくフィードバックを得るのが難しい理由です。

情報をもっと広めることができれば、もっと多くの人がこれに興味を持ってくれると思います。 それはあなたが探しているリソースが許すものですか？

jriddyが言っていることを続けるために、さまざまな機能フラグについて知っておく必要がある場合、新しいフラグごとにCI設定を変更するなど、さまざまな機能フラグをテストするのは非常に難しいと思います。

ただし、はるかに実行可能と思われるのは、知っておくべき1つの機能フラグしかない場合、テストする必要のある変更に関して「次に何が起こるか」をテストすることです。 そうすれば、人々や企業は、CIをセットアップしてそれも実行できるようになります（エラーのビルドに失敗することはありません）。 私はRustに似たものを考えています。このような変更は、ツールチェーンの「ベータ」チャネルで行われ、別のCIチャネルをセットアップして、ベータツールチェーンで実行し、エラーを誰かに送信するのは簡単です。

重要なことは、このセットアップは、新しい個々の機能フラグについて継続的に学習したり、CIセットアップを変更したり、手動でテストしたりするのではなく、_一度だけ_学習して実行する必要があるということです。

ただし、はるかに実行可能と思われるのは、知っておくべき機能フラグが1つしかない場合です。

ある意味で、これはすでに--preの形で存在していませんか？ pipのベータリリースチャネルは、 pip install --upgrade --pre pipを実行するだけの問題でしょうか？

飛び込んで申し訳ありませんが、これが前進するのを見てうれしいです！

@techalchemyお願いします、すべての人々の中で、_あなた_は間違いなくこの議論で売り込むことを後悔する必要はありません。

それはあなたが探しているリソースが許すものですか？

ある程度、はい。

reg：ベータリリース/ pipの「チャネル」

@jriddyと@ chrish42でチャイムを鳴らしてくれてありがとう。 一般的に、それは確かに有用で重要な会話だと思いますが、この問題については少しOTだと思います。 それでも、ここで一度応答します。 これについてもっと話し合いたいのなら、新しい問題を開いてみましょう。

過去に（最近ではpip 10で）それを試しましたが、うまくいきませんでした。 私はそれが今後どれほどうまくいくかについて少し懐疑的ですが、私たちのプロセスにいくつかの変更を加えると、これが私たちにとってスムーズに機能するようになるかもしれないと想像することもできます。 たぶん、「ベータ版のみ」の機能セットなどを実行できるでしょうか。 ＃5727の構文として-X allを想像しました。 たぶん、この展開計画の一部としてそれを取り上げることができますか？ Idk。 これを理解するには、時間とエネルギーを投資する必要があります。 :)

https://github.com/pypa/packaging-problems/issues/25#issuecomment -520167480で述べたように、ソルバーがピップエクスペリエンスをどのように変更するかを統合的に説明することが重要だと思います。 多くの人々は、より厳格なシステムへの移行に不満を感じるでしょう（全体的に信頼性が高いはずですが、現在ブロックされていない場所ではブロックされます。

物事がどのように変化したか、そしてなぜそれが良い変化であるかについての中心的な説明を持つことは、それらの怒っている人々への対応をはるかに簡単にするでしょう。 リンクを投稿して、さらに質問があるかどうかを確認してください。

プレリリースは良い考えです。 condaには、プレリリースチャネルのconda-canaryがあります。 コンダの変更によってカナリアが破壊されるかどうかを確認できるように、カナリアに対して実行するCIジョブを設定することをお勧めします。 理想的には、そのバージョンをリリースする前に、彼らは私たちに知らせてくれます。 そのチャネルはかなり悲惨な失敗でした。 人々が実際にそれを使用しているように見えるのは、彼らが苦労しているいくつかのバグを修正するために最新のリリースを入手したいときだけです。 意図したアーリーアダプターからの報告はあまりありません。 プレリリースはまだ良い考えだと思います。リリースがうまくいかず、700の管理対象ノードを壊したことに人々が腹を立てているときは、「まあ、リリースする前の1週間は利用可能でした。なぜですか？ 700ノードにロールアウトする前にこれらをテストしますか？」 あなたは人々に物事をより良くする機会を与えています。 その機会を逃すことは、将来的に彼らにとってより多くの苦痛を意味することを彼らが理解するのを助けてください。 それは彼らにとって価値のある投資であり、彼らがCIの一部としてそれを行う場合、セットアップ以外の時間はかかりません。

フラグについて：（おそらくフラグに加えて）構成オプションがある方が良いと思います。 私はいつも旗を渡したくありません。 pipにこの機能があるかどうかはわかりませんが、より永続的なスイッチが必要な人に、対応するenv変数を使用するように指示しますか？

旗について：

pipのCLIオプションは、適切な名前で、構成ファイルオプションと環境変数に自動的にマップされます。

@msarahanチャイムをしてくれてありがとう、大いに感謝します！ :)

壊れた依存関係を無視する「やりたいことをやらせて」オプションに関しては、リゾルバーがデフォルトでオンになった後のオプトアウトとしても機能するように機能フラグを構成することが望ましいと思います（たとえば、オプトインとして--avoid-conflictsを使用し、最終的にオプトアウトとして--no-avoid-conflictsに移動しますが、最初から両方のオプションを受け入れます）

また、 --ignore-installedがソルバーとどのように相互作用するかを検討する必要があります。ソルバーが渡された場合、既にインストールされているパッケージのすべての要件を無視する必要があります。

それ以上に、リゾルバーの統合を容易にするための小さなリファクタリングパッチとして処理することは、優れた方法です（これが、CPythonの新しい構成APIを可能にしたアプローチです。多くのプライベートリファクタリングは、最終的には公開するのに十分安定していました）

@ncoghlanリゾルバーの「オプトアウト」とはどういう意味ですか？ 依存関係の解決（したがってリゾルバー）を完全に回避するのは--no-depsです。 「このパッケージのバージョンの競合を無視する」などの必要があることを理解しています。

個人的には、新しいリゾルバーへの移行期間よりも長く「最初に見たままにする」解決ロジックを維持することに意味はありません。

ただし、これら2つのオプションでカバーできないユースケースがある場合は、それらについて本当に知りたいと思います。 :)

より広義には、厳密なリゾルバーの動作に問題があるワークフローがある場合、それらをサポートするかどうか/どのようにサポートするかを理解できるように、それらがどのように見えるかをできるだけ早く知りたいと思います。

個人的には、新しいリゾルバーへの移行期間よりも長く「最初に見たままにする」解決ロジックを維持することに意味はありません。

IDK、私はこの「機能」を使用して、ビルドでかなりクレイジーなことをします。

# install just the packages I've built specifically
pip install --no-index --no-deps --find-links=/path/to/my/local/build/cache -r local-reqs.txt

# ...snip to later in a dockerfile, etc...

# install the deps from public PyPI
pip install -r local-reqs.txt

この場合、ローカルの操舵室からいくつかの非常に事前に決定されたパッケージをインストールした後、依存関係を解決するように依頼しています。 正確なバージョンをそのlocal-reqsファイルに読み込んでリゾルバーを満足させることができると思いますが、実際には、pipの現在の動作が、このような任意のビルドインジェクションステップを可能にするのに非常に役立つことがわかりました。 スペースバーの加熱ワークフローの場合かもしれませんが、私は認めます。

しかし、おそらく「ナイーブな解決」の振る舞いにはまだ用途があります。

@pradyunsgに同意します。 既存のコードと新しいリゾルバーを無期限に維持することは実行可能ではないと思います。 確かに、ピップメンテナーとして、私はそれをすることに興味がありません。

エンドユーザーのPOVから、新しいリゾルバーが正しいことを行わない可能性があるという奇妙なシナリオが存在する可能性があることを認めます。 また、緊急の「古い動作を返してください」フラグを設定することは、重要な移行メカニズムです（ただし、「一時的に以前のバージョンのpipにロールバックする」のが同じくらい良いわけではないかどうかは議論の余地がありますが、CIの一般的な使用法のようなものは自動的に最新のpipを使用して、そのオプションを問題のあるものにします）。 しかし、長期的には、なぜ現在の動作を維持する必要があるのでしょうか。 私は次の主な状況を想像することができます：

1. レゾルバのバグ。 明らかな可能性、簡単な修正-pipの次のリリースでバグを修正します。
2. 古いリゾルバーが間違っている場合（制約を満たさない結果が生成されます）。 今後はそれをサポートするつもりはありませんよね？ （少なくとも、ユーザーが必要なものを固定し、 --no-depsを使用してリゾルバーをオフにするよりも極端な方法ではありません）。
3. 古いリゾルバーと新しいリゾルバーで異なる結果が得られ、どちらも指定された制約を満たす場合。 ユーザーは制約を追加して古い結果を強制することができます（できない場合は、（2）に戻ります）。 そうする時間を与える必要がありますが、他の非推奨の機能と同様に、古いリゾルバーを削除します。
4. 複雑すぎてサポートできないと考えるエッジケース。 これは（3）に似ていますが、新しいリゾルバーが「正しい」結果をもたらすとは断言していません。 ユーザーは、奇妙なケースを回避するために制約を変更したり、 --no-depsを固定して使用したりできます。 しかし、最終的には「そうしないでください」と言っており、ユーザーがそのメッセージを無視した場合は、ある時点で、「警告しました」という古いリゾルバーを削除します。

私が逃した他のものはありますか？ 特に、古いリゾルバーを廃止してから削除することができない場合はありますか？

ちなみに、迷子にならないように「考えたエッジケースはこちら」のシナリオを投稿するのに最適な場所はどこですか？ テストケースの作成を早期に開始できるのであれば、事前にできるだけ多くの奇妙な状況を収集しておくと便利だと思います:-)

PSおそらく、新しいリゾルバーの準備作業の一環として、「典型的な」制約の問題が何であるかを調査する必要があります（PyPIの内容に基づいて）。 私自身の部分では、「pipinstall」よりも複雑なものがあることは非常にまれです。「。複雑なケースで行き詰まり、単純なケースの大部分を見失うのは残念です。

1. リゾルバが遅すぎます（condaを参照）。 20分以上のリゾルバー、または現在の動作のいずれかを選択する必要がある場合は、現在の動作が必要になることがよくあります（または、少なくとも試してみてください。多くの場合、問題のない結果が得られます）。

2. メタデータが間違っています。 今日はそれほど問題ではありませんが、解決できるはずなのに解決できないケースを想像するのは簡単です。 PyPIメタデータはconda / conda-forgeメタデータよりも悪い形であり、それはすでにcondaの問題です。 それが間違っていて、ユーザーとして解決策を得ることができない場合は、オプトアウトを取得したいと思います。

@rgommers 6の場合、「このパッケージのバージョンの競合を無視する」スタイルのオプションが機能する可能性があります。

ありがとう、 @ rgommers-それらは良い点です。

リゾルバーが遅すぎるので、リゾルバーのバグとして数えます。 単純なケースで十分なパフォーマンスの結果が得られない場合、それは私の見解では目的に適合しません。 一方、完全なリゾルバーを使用すると時間がかかる非常に複雑な制約ネットワークがある場合（20分が誇張であるといいのですが、どのような状況でも許容できるとは思いません！）、「領域をサポートするには複雑すぎると考えてください。 別の言い方をすれば、誰かがcondaに「速くて汚い」不正確であるが速い解決策を提供するように頼もうとしたことがありますか？ 彼らがそうしないのなら（そして私は彼らがそうしないだろうと私はかなり確信している）、なぜピップを期待するのが合理的ですか？

悪いメタデータは間違いなく「私たちはそれをサポートしない」と私が考えるものです（ここでは「非推奨期間の後」について話していることを忘れないでください！）。 ユーザーにメタデータを修正する時間を与え、「パッケージXでのバージョンの競合を無視する」エスケープ句オプションを提供することは、IMOで十分です。一部の人々がメタデータを修正しないという理由だけで、古い機械をすべて保持することを期待すべきではありません。

しかし、そうです。正確なリゾルバーが「ガベージイン、ガベージアウト」ルールに従うため、優れたメタデータが必要であるという事実を公表し、人々がそのメッセージにどのように応答するかを監視することは、ロールアウトプロセスの大部分を占めています。

地元の操舵室から非常に事前に決定されたパッケージをいくつかインストールした後、依存関係を解決するように依頼しています。

@jriddy 「互換性がある場合は既存のインストールを使用する」という解決戦略がこれに有効です。

迷子にならないように、「私が考えたエッジケースはここにあります」シナリオを投稿するのに最適な場所はどこですか？

https://github.com/pradyunsg/zazo/

6の場合、「このパッケージのバージョンの競合を無視する」スタイルのオプションが機能する可能性があります。

はい、それは正しいオプションのように聞こえます

（20分が誇張であるといいのですが、どのような状況でも受け入れられるとは思いません！）次に、「サポートするには複雑すぎると思われるもの」の領域に入ります。 別の言い方をすれば、誰かがcondaに「速くて汚い」不正確であるが速い解決策を提供するように頼もうとしたことがありますか？ 彼らがそうしないのなら（そして私は彼らがそうしないだろうと私はかなり確信している）、なぜピップを期待するのが合理的ですか？

condaのパフォーマンスについて不満を言っている人はたくさんいて、聞いていますが、それは大変な作業です。最近のブログ投稿を参照してください。 迅速で汚いコンダオプションがあるかどうかはわかりません。 ただし、 conda-metachannelのような関連するソリューション（ハック）があり、依存関係グラフ（手動でパッケージを含める/除外する）を整理して、ソリューションをより速く取得できます。 だから私はそれが同じ線に沿っていると思います。

ただし、次のいずれかを行わない限り、これは_間違いなく_必要になることに注意してください。

• すぐにコンダよりもはるかに優れた仕事をします（そうは思われませんが、彼らが何をしているのかわからないわけではありません-それは本当に厄介な問題です）。
• 解決すべき問題が小さい（うまくいけば真実ではない、PyPIは大きく、優れたメタデータがあれば問題は大きくなるはずです）

悪いメタデータは間違いなく「私たちはそれをサポートしない」と私が考えるものです

けっこうだ。 ただし、「正しいメタデータを適用しない」というスタンス全体は、ここでは役に立ちません。 それが最近変わっていない限り？ （そして私は知っています、それはpipのものではなくPyPIのものです-しかしそれは関連しています）。

あなたが本当にあなたがそうすると思うオプションを持っているかどうかはわかりません。

速くて汚いリゾルバーは正確なものと何が違うのですか？ 何が速くなるのですか？ 制約は制約であり、グレードには含まれていません。 あなたは彼らを満足させるか、満足させないかのどちらかです。 おそらく、最初は名前だけで、次にバージョンなどでそれらを満足させることができます。

Condaが遅いことに人々が腹を立てているとき、それは本質的に常に悪いメタデータが原因です。 根本的な原因に関係なく、知覚される速度低下のせいになることを覚えておいてください。 不正なメタデータは、誤った制約である場合がありますが、多くの場合、はるかに古い、望ましくないオプションを検討できる制約がないことが原因です。 Condaは最近、1つの小さなことを行うことで大幅に改善しました。それは、不十分な（ほとんどの場合オープンすぎる）制約があった古いソフトウェアのコレクションを削除することです。 これらのオープンな制約により、condaは多くのダウングレードを必要とする本当に悪いソリューションを探求しました。 これは、解決に文字通り何時間もかかった場所です。 ダウングレードは、カスケードできるため、非常にコストのかかる操作であり、各ステップの制約が少なくなり、コストが高くなります。

メンタリティとしての「ガベージイン、ガベージアウト」の問題は、ソルバーのメンテナとして、バッグを持っていることです。 ゴミとは何かについて非常に優れたヒューリスティックがない限り、あなたは無力です。 最終的には、ソルバーが遅い理由を調査し、問題のパッケージを切り分けてから、問題の原因に問題の修正を依頼する必要があります。 そこにいるのは素晴らしい立場ではありません、私を信じてください。 私たちは、コンダが永遠に続く理由、またはコンダフォージ、バイオコンダ、または他のサードパーティチャネルの混合物で機能しない理由を人々に説明するために多くの時間を費やしています。 結局、探偵の仕事をし、それらのサードパーティのチャネルに何を修正する必要があるかを伝える必要があります。 最悪だ。

condaとの比較では、condaが問題に対して非常に異なるアプローチを取っていることを考慮する必要があります。 Condaには1つの巨大なメタデータソースがあり、すべてを一度に解決しますが、pipは一度に各ものを再帰的に解決して最適化します（必要に応じてバックトラックします）。 それはあなたに異なる最適化パスを与えるかもしれません。

@wolfvは最近、condaにlibsolvを使用することを検討しました。 彼は最終的に、コンダと同じ答えを出すことができなかったことに不満を感じました。 それは、アプローチ間のこの違いに要約されます。 Libsolvはバックトラッキングソルバーです。 コンパイルされたコードをpipに直接含めないことに敏感であることは知っていますが、これはpipへのオプションのコンパイル済みアドオンとして機能する可能性があります。

（ @pradyunsgは、8月の更新をブログに投稿しました。）

人々が今提起している質問やニーズのいくつかは、テストケースなど、今すぐ収集を開始する必要があるものです。

しかしまた、この展開ではどのようなタイムラインが現実的であると考えていますか？ これは、Pradyunの健康状態と自由時間、他のpipメンテナからのコードレビューの可用性、および申請している助成金を取得できるかどうかに大きく依存しますが、シーケンスは次のようになります。

• ロジックリファクタリングの構築：進行中、12月から2月のいずれかに実行
• UXの調査と設計、インフラストラクチャの構築のテスト、構成フラグと移行スケジュールについてのダウンストリームとユーザーとの話し合い：これには資金が必要です。 最も早い開始はおそらく12月で、2〜3か月かかります
• アルファテストの実行中にresolvelib/zazoで定義された抽象化を導入します。数か月かかるので、控えめに見積もって、2020年5月ですか？
• より良い依存関係の解決を採用し、ベータテストを行います：？

これは正しいですか？ 私は何が欠けていますか？

私の意見では、情報収集作業の一部はプロジェクトマネージャーやUX研究者が行うべきものであり、 https：//github.com/pypa/packaging-problems/issues/264と他の問題は、人々がここで提起した懸念に役立つ可能性があります。

不正なメタデータは、誤った制約である場合がありますが、多くの場合、はるかに古い、望ましくないオプションを検討できる制約がないことが原因です。

制約のない依存関係または>= some_old_versionを使用することが、 setup.py / pyproject.tomlの例外ではなくルールであるため、これは問題になります。 それが「誤った制約」であるか、ソルバーが異なる選択を行う必要があるかどうかは、私は本当に気にしません。これは、PyPIのメタデータの状態です。

これらのオープンな制約により、condaは多くのダウングレードを必要とする本当に悪いソリューションを探求しました。

あなたはここの専門家ですが、これに対する実用的な解決策はありませんか？ ほとんどの場合、ダウングレードは必要ないため、最初にダウングレードのみを試してください。 次に、パッケージごとに1つのバージョンのみをダウングレードします。 さらにダウングレードする必要がある場合、それはほとんどの場合間違った解決策です（メタデータの不良などが原因である可能性があります）。

実際、 pipがダウングレードできるかどうかはわかりません。 最初はあまりにも積極的な「すべてをアップグレードする」戦略でしたが、今では「必要に応じてアップグレードする」が非常にうまく機能します。 私はそれが何かをダウングレードするのを見たことがありません、そして実際にはそれは通常の使用のためにかなりうまく機能します。

condaが対処しなければならないダウングレードの例ですが、pipは対処しません。python3を使用するanacondaまたはminicondaのユーザーは、python3.7から開始します。 ユーザーは、Python3.6でのみ利用可能なものをインストールする必要がある場合があります。 ソルバーは、Pythonおよびその他すべての非noarchパッケージをダウングレードする必要があります。 これは、Pythonバージョンの変更に対して特別な動作を行うことで最適化できる可能性のある特殊なケースですが、あるパッケージの変更で別のパッケージへのダウングレードが必要になる可能性があることを示しています。 「これまでのところうまくいった」というのは運が悪いことであり、実際にいつもうまくいくことではありません。

バージョンの制限については、ソルブ自体に適用することはできません。 あなたには制約があり、どんな種類の「1つのバージョンで開く」ことは、パッケージごとに異なるため、十分に一般的であることを期待することはできません。 ただし、ソルバーの前にバージョンごとにメタデータを切り取ることができます。 これが、condaの「current_repodata.json」です。 最新バージョンのみ。 それが機能するとき、それは物事を本当に速くします、しかしそれが唯一のレポデータであるならば人々は本当に怒るでしょう。 物事は再現可能ではなく、ある日は機能するスペックが次の日には機能しない可能性があることに不満を感じるでしょう。 完全なリポジトリデータへのフォールバックを提供し、特定の時点で利用可能な最新バージョンのみを使用して、時間ベースのサブセットを導入することも計画しています。 利用可能なインデックスデータを段階的に開くことは、バックトラッキングソルバーを使用する場合のより便利な概念である可能性があります。

pip _ can_は物事をダウングレードすることさえできます。

それは可能です-pipの場合、ダウングレードはアップグレードのようなアンインストール-インストールステップです。 そして、満たすように求められた制約を検出すると、ダウングレードします。

以下はsetuptoolsをダウングレードします-それがpipが最初に見るものである限り：

pip install "setuptools < 20.0"

迷子にならないように、「私が考えたエッジケースはここにあります」シナリオを投稿するのに最適な場所はどこですか？

https://github.com/pradyunsg/zazo/

ありがとう、私はそれを心に留めておきます。 再考しましたが、私の「病理学的症例」は実際にはそれほど病理学的ではありません。 これはほとんどの場合、パッケージの依存関係メタデータを知るために、パッケージをダウンロードして解凍する必要があるという事実の極端なケースです。場合によっては、これにより、多くのパッケージのダウンロードがトリガーされ、それらが拒否される可能性があります。 これは、対処する必要のある「単純なインデックス」プロトコルの重要な制限である可能性がありますが、直接リゾルバーの問題ではありません。

condaが対処しなければならないダウングレードの例ですが、pipは対処しません。python3を使用するanacondaまたはminicondaのユーザーは、python3.7から開始します。 ユーザーは、Python3.6でのみ利用可能なものをインストールする必要がある場合があります。 ソルバーは、Pythonおよびその他すべての非noarchパッケージをダウングレードする必要があります。 これは、Pythonバージョンの変更に対して特別な動作を行うことで最適化できる可能性のある特殊なケースですが、あるパッケージの変更で別のパッケージへのダウングレードが必要になる可能性があることを示しています。 「これまでのところうまくいった」というのは運が悪いことであり、実際にいつもうまくいくことではありません。

また、通常は_ダウングレードしたくない_場合もあります。 ユーザーとしては、パッケージが利用できないという例外が発生します。必要に応じて、3.6を明示的にインストールします。

もう1つの例は、チャネル間の不整合です。 最近の例：Python 3.7.3を使用していた場合、 baseは3.7.4 $を取得しました。 私はそれらのバージョンの違いを気にしません、そしてほとんどのユーザーは気にしません。 デフォルトの「何もしない」は、「ちょっと.4 > .3 、それをアップグレードしてから、必要に応じて他のパッケージのチャネルをbaseに変更しましょう（ダウングレードする場合でも）」よりもはるかに優れています。

完全なリポジトリデータへのフォールバックを提供し、特定の時点で利用可能な最新バージョンのみを使用して、時間ベースのサブセットを導入することも計画しています。

それは非常に有用な改善のように聞こえます。

メンタリティとしての「ガベージイン、ガベージアウト」の問題は、ソルバーのメンテナとして、バッグを持っていることです。 ゴミとは何かについて非常に優れたヒューリスティックがない限り、あなたは無力です。

ええ、それは本当です。 すべてのIDE、ディストリビューション、または「たくさんのものへの共通インターフェース」にこの問題があると思います。

以下はsetuptoolsダウングレードします

これは、ユーザーが要求したダウングレードです。 間接的なものは私が意味したものです（例えば、pyproject.toml`のsetuptools<20.0 ）。 それもうまくいくと思いますが、実際にはまれです。

メンタリティとしての「ガベージイン、ガベージアウト」の問題は、ソルバーのメンテナとして、バッグを持っていることです。

100％同意しました。 それは非常に注意深く扱われなければならないものです。 しかし、逆に、古いジャンクに対して適切な動作を実行しようとすることは実行可能ではありません。どこかに線を引く必要があります。

念のため、この議論は、既存のリゾルバーを無期限に保持する必要があるかどうかという質問によって引き起こされました。 これらの点のいずれかが実際にその質問に影響を与えるかどうかはわかりません。既存のリゾルバーは正しくありません。最もよく言えるのは、人々が慣れ親しんでいるのは壊れた動作だということです。 したがって、私は上記のことを支持します。最初の移行期間を超えて古いリゾルバーを保持する理由はありません。

そして実際には、ユースケースの大部分について、新旧のリゾルバーはとにかく同じ結果をもたらす可能性があります。

ユーザーがあなたの変更によって壊れたとき、「正しい」はユーザーにとって重要ではありません。 動作の変更は、一部のユーザーを完全に激怒させます。 彼らのワークフローが間違っていて、変更する必要があることを彼らに伝えることは、私にとってそれほど効果的な戦略ではありませんでした。 耳で弾く必要があると思います。 私は確かに古いリゾルバーを永久に維持したくはありませんが、おそらく他の誰かが採用して維持するプラグインにするなど、それを維持するためのパスを人々に与える必要があります。人々はそれをpipとは別にインストールできます。

古いがらくたのために正しい振る舞いを解決しようとすることは実行可能ではありません-どこかに線を引く必要があります。

はい、でも「古いジャンク」とは何ですか？ 何がそれを区別しますか？ 悪いジャンクと良いジャンクはどうですか（新しい方が常に良いとは限らないことを念頭に置いて）？ 私のアドバイスは、ソルバーを非常にデバッグ可能にするために多くの時間を費やすことです。 悪いメタデータが問題である場合、およびその悪いメタデータが何であるかを簡単に識別できるように、ユーザー（専門家としてのあなただけでなく）が物事が横向きになっている場所を簡単に追跡できるようにします。 これは現在ほとんどのユーザーが持っていないスキルであり、正直なところ、私が見たほとんどのユーザーはこのスキルを持ちたくないと思っています。 あなた（またはそのことについてはコンダ）が、悪い対良いの完全に正確な自動ヒューリスティックを持つことができるとは思わない。

また、通常はダウングレードしたくない場合もあります。 ユーザーとしては、パッケージが利用できないという例外が発生します。必要に応じて、3.6を明示的にインストールします。

@ rgommers 、conda4.7はこれに移行しました-マイナーバージョンを変更するには明示的なPython仕様が必要です。 人々はそれを嫌っています。 ボーカルの人口の何分の1かはわかりませんが、多くの人は、以前はconda installができたのが本当に嫌いでしたが、今はできません。 彼らは理由をあまり気にせず、答えによってほとんど混乱しますが、それでも私たちは敵意を持って対処することができます。 のちょうど別の例

ユーザーがあなたの変更によって壊れたとき、「正しい」はユーザーにとって重要ではありません。

もう1つの例は、チャネル間の不整合です。 最近の例：Python 3.7.3を使用していた後、ベースは3.7.4になりました。 私はそれらのバージョンの違いを気にしません、そしてほとんどのユーザーは気にしません。 デフォルトの「何もしない」は、「ちょっと.4> .3、それをアップグレードしてから、必要に応じて他のパッケージのチャネルをベースに変更しましょう（ダウングレードする場合でも）」よりもはるかに優れています。

これははるかに複雑な点です。 基本的に、さまざまな最適化基準を提案しています。 https://www.anaconda.com/understanding-and-improving-condas-performance/のブログ投稿で現在の11のステップを見たことがあるかもしれません。

これらは非常にトリッキーであり、すべての状況を満足させるグローバルな最適化はありません。 バイナリ互換性と、前述の互換性の島としてのチャネルを考えると、チャネルの強力な優先順位は非常に重要です。 Pythonのビルドは重要ではありません、あなたは正しいですが、現在、バイナリ互換性制約とプレーンで単純なバージョン制約を表現する方法はありません。 あなたはただ物事を放っておくというあなたの考えについて考えるためにそれを必要とするでしょう。 そうでなければ、あなたはすぐにバイナリの非互換性の地獄にいるでしょう。

こんにちは、この問題で私に言及してくれた@msarahanに感謝します。 以前にチャイムを鳴らしたかったのですが、時間が見つかりませんでした。

実際、私はコンダ仕様のソルバーとしてlibsolvを使用してかなり実験しました。 そして、それは機能します-残りの違いは、condaはビルド番号をあまり気にしないということですが、コード化された方法で（そしてバックトラッキングソルバーを使用して）libsolvは機能します。 完全なrepodataを使用している場合でも、libsolvは非常に高速です。libsolvの速度は、煩わしくないほど高速であると言っても過言ではありません:)

libsolvへの私の大きな貢献は、クロスプラットフォーム互換にして、Windows、OS X、およびLinuxでコンパイルできるようにすることでした。

コンパイルされたコードのブロブであり（少なくとも高速です）、 @ mlschroeが役立つ可能性がありますが、新しいリゾルバーにはlibsolvを使用することを完全に推奨します。彼は、libsolvのサポートで多くのことを支援しました。 condamatchspec。

一方で、リゾルバーの開発がどの段階にあるのか、もう手遅れなのか、コンパイルされたコードが受け入れられるのかどうかはわかりません。

https://www.anaconda.com/understanding-and-improving-condas-performance/のブログ投稿で現在の11のステップを見たことがあるかもしれません。

確かに私はしました。 それは素晴らしいブログ投稿でした。

基本的に、さまざまな最適化基準を提案しています。

あまり。 あなたの_ "バイナリ互換性制約とプレーンでシンプルなバージョンの制約" _は、おそらく私が見逃しているものを指し示していると思います。 私が期待しているのは、メタデータにpython >= 3.7.4または== 3.7.4が含まれるパッケージはなく、常に== 3.7であるということです（scipyをチェックしただけで、 meta.yamlはpythonと言いますconda_forge.ymlはmax_py_ver: '37' $と言います-理にかなっています）。 したがって、 3.7.4を導入しても何も起こりません-リゾルバーが3.7.3を選択し、他に何も変更しないことは、 3.7.4を強制してトリガーするよりもはるかに安価です（そして11のステップに従って有効です）。アップ/ダウングレードのチェーン。

この部分はpipの展開計画で話題から外れていると思いますので、これを別の場所に持っていってください。

私のアドバイスは、ソルバーを非常にデバッグ可能にするために多くの時間を費やすことです。

+1

また、可能な限り修復可能にします（保持します）。 これはpipの良いところです。通常、混乱した場合はcd site-packages && rm -rf troublesome_packageを実行でき（おそらく--no-depsで再インストールした後）、問題は解決します。 conda 、 aptのようなものや友人は、その方法で修復するのがはるかに困難です。

基本的に、さまざまな最適化基準を提案しています。

チャネルの概念を十分に考えているとは思いません。 ピップすることがどれほど関連性があるのか​​わかりません。 コンダよりも間違いなくはるかに少ないですが、それが完全に無関係であるかどうかはわかりません。 人々はまだ一度に複数のインデックスからパッケージを集めることができますよね？

パッケージにはpython> = 3.7.4も、== 3.7.4もありません。 コンダパッケージの標準は、上限と下限を設定することです。 これらは通常、互換性のある範囲を検討するバージョンの場所の数に関してレシピ作成者から提供された情報を使用して、conda-buildによって自動的に決定されます。 パッケージには> = 3.7.2、<3.8.0a0のような制約があり、プレリリースバージョンが.0リリース未満であるという事実を説明するために、0a0の厄介さがあり、したがって、人々が一致しない<3.8.0仕様に一致します。本当に期待しています。

パッケージには、チャネルも関連付けられています。 このチャネルは事実上バージョン最適化の一部です： https ：//github.com/conda/conda/blob/4.6.7/conda/resolve.py#L1074-チャネルはスーパーバージョンのようなもので、パッケージのメジャーバージョン。 解決によってPythonが変更されない場合、Pythonの仕様をpython == 3.7にすることはできません。これは範囲であり、チャネルはその範囲に影響します。 具体的には、python == 3.7仕様で、 defaultsチャネルからのインストールから開始し、 conda-forgeチャネルを追加すると、多くのチャーンが発生します。これは、新しいpythonパッケージを導入したためです。 「バージョン」（チャネルを含む）が高く、Python仕様はその変更を許容します。

Conda 4.7は、スペックのはるかに積極的な「フリーズ」を導入しました。私は、動作があなたが求めているものであると確信しています。 しかし、それはかなり複雑です。 つまり、明示的な仕様と競合しないものだけをフリーズすることになります。 「対立」をどのように判断するかが難しい部分です。 ソルバーがユーザーにそのパッケージの依存関係のグラフの一部である最新のパッケージを提供するのを妨げるようなものをフリーズしない方がよいと思います。 この凍結は、コンダでは不可能な方法でピップの仕様ごとに実行できるため、言及する価値があります。 これは、バックトラッキングソルバーの優れた最適化になると思います。

また、可能な限り修復可能にします（保持します）。 これは、pipの優れた点です。通常、混乱した場合は、cd site-packages && rm -rftroublesome_package（おそらく--no-depsを使用して再インストールする）を実行でき、問題は解決します。 conda、apt、friendsのようなものは、その方法で修復するのがはるかに困難です。

はい、これは非常に重要です。 ピップは物事を慎重に売り込むという良い仕事をしてくれたので、壊れにくくなっていると思います。 それは非常に賢明であり、コンダはそれから学んでいます。 コンパイルされたコードを使用することになった場合は、静的にリンクされているか、動的ロードによって問題が発生する可能性がないことを確認してください。

（libsolvタンジェント：以前RHで働いていたとき、libsolvビルドプロセスは生成しないため、https：//pypi.org/project/solv/を取得してFedoraの「pipinstallsolv」セキュリティの抜け穴を閉じました。現時点では、sdistまたはwheelアーカイブはもちろん、PyPIに公開します。現在の無害なプレースホルダーではなく、libsolvのバンドルコピーを使用して実際のライブラリバインディングを作成することに関心がある人とチャットできます）

「オプトアウト」コメントに関しては、「古いインストールロジックにフォールバックする」という意味ではなく、「インストールリクエスト全体を失敗させるのではなく、制約違反の原因となるパッケージのインストールをスキップするオプションを提供する」という意味です。

Yum / DNFは、 --skip-brokenオプションを介してそれを提供します（DNFでは、そのフラグは--setopt=strict=0のエイリアスです）。 pipのリゾルバーも同様のオプションを提供する必要があると思います。

@ncoghlanああそうだね。 それは理にかなっている。

「このパッケージのバージョンの競合を無視する」スタイルオプション

そうすることはすでに述べたので、あなたのコメントに戸惑いました。

その時、私たちは同じページにいます。 :)

@ncoghlanは、 distutils-sigで提案されたタイムラインに返信し、合理的に聞こえると述べました。

@ pradyunsg-次の毎月の更新を楽しみにしています！

私はこれをもう一度見て時間をかけて、＃7317を提出しました。

抽象化はほぼ完了していると思います。pipのインデックスの相互作用、依存関係の解決+ビルドロジックの分離、および一連の一般的なクリーンアップに関する多くの作業のおかげです。

＃7317を閉じました。 私の知る限り、依存関係の解決はメタデータビルドロジックから（十分に）切り離されています。 ビルドロジックのリファクタリングは順調に進んでおり、今後の進歩を妨げるものではなくなりました。

これで、[passa]と必要に応じて詩のリゾルバーから参照して、pipでの[resolvelib]抽象化の実装に取り​​掛かることができます。 :)

@pradyunsg Poetryコードベースからベースリゾルバー（PubGrubに基づく）を抽出することを計画しています（https://github.com/sdispater/poetry/tree/master/poetry/mixologyを参照）。 ほとんどの場合、コードの残りの部分から切り離されていますが、抽象化する必要のある内部部分への参照がまだあります。

あなたがそれを手伝うことに興味があるなら、私に知らせてください。 アイデアは、サードパーティが使用できるPubGrubアルゴリズムのスタンドアロン実装を用意し、現在古いリゾルバーのコードを保持しているhttps://pypi.org/project/mixology/に配置することです。

@sdispater間違いなく！ 私が直接助けることができるかどうかはわかりませんが（時間の制約）、PubGrubポートを他の詩から切り離すことができれば素晴らしいでしょう！

本当に素晴らしいことの1つは、pip、poetry、pipenvが同じ抽象化を使用するように、一貫した抽象化レイヤーを持つことです。 現在、zazo（mine）、mixology（poetry's）、resolvelib（pipenv's）があります。これらはすべて、ある種の抽象化レイヤーを定義しており、わずかに異なりますが（ばかげて！）似ています。 あなたがこれにオープンであるならば、私たちに知らせてください！

参考までに、私たち（ @wolfv 、および一般的には@QuantStackチーム）は、pip依存関係リゾルバーのRfPに応答しました。

提案されているアプローチは、 libsolv Cライブラリを採用し、pipのバージョン制約形式のサポートをlibsolvに提供することです。 新しいPythonバインディングを介してCライブラリを公開します。

Libsolvは、RPMエコシステムの基盤となる強化されたライブラリであるため、すでに産業規模で使用されています。

• Libsolvは、BSD-3-Clauseライセンスの下で配布されています。
• Libsolvは、 rpm 、 debなどの複数のパッケージとリポジトリ形式をサポートしています。
  haiku 、 conda 、 arch 。 重要なのは、さまざまな形式と表現方法です
  依存関係の制約は、それが可能であるはずのプラグ可能なシステムであることを示しています
  依存関係バージョンの制約に対するpipの構文に対応するため。
• シンマンバラッパーでcondaのソルバーの代わりにlibsolvを使用すると、
  コンダのパフォーマンスを大幅に向上させることができます。 （大規模なチャネルでのパッケージ解決におけるcondaの遅さは、mambaに取り組むための私たちの主な動機でした）。
• Windows、OS X、Linuxでクロスプラットフォームで動作します。 （ @wolfvはlibsolvのWindowsポートを実行しました）
• 完全なSAT解決を実行して、最適な依存関係の組み合わせを見つけます。成功しなかった場合は、競合を解決するための実用的なヒントを返します。

提案されているアプローチは、libsolvCライブラリを採用することです。

libsolvがサポートしていないプラットフォームのフォールバックが必要になります（たとえば、pipでのAIXサポートは積極的に取り組んでおり、BSDについては言及していません）。 したがって、利用可能な場合のパフォーマンスオプションとしてのlibsolvは私にはもっともらしいですが、実際にはそれだけを使用する立場にはありません。 （libsolveの純粋なPythonバージョン、つまり同じ結果をもたらすものがありますか？）

また、get-pip.pyはどのように機能しますか？ 考えられるすべてのプラットフォームのlibsolvのバイナリを含める必要がありますか？ 繰り返しますが、私はそうではないと思います、私たちは純粋なPythonフォールバックを使用します。

外部のCコードを使用できないことは、長い間pipにとって厄介なことでした。 良い解決策を見たいのですが、（a）（完全にベンダーを排除できる「ミニピップ」ブートストラッパーソリューションの形式が不足している）ものがあるかどうかはわかりません。（b）それは私がそれに依存する新しいリゾルバーを嫌うほど大きな作品です。

こんにちは@pfmoore

libsolvはかなり単純なCコードであるため、追加のプラットフォームサポートを実現するのはそれほど難しいことではないと思います。 libsolvの純粋なPythonバージョンはないと確信しています（これは欠点だと理解していますが、Pythonの純粋なPythonバージョンやPython標準ライブラリもありません。したがって、私の考えでは、ブロッカー）。

ブートストラップの場合、現在のメカニズムを使用して解決する純粋なPython pipを使用できます。これにより、libsolvに基づいて必要なリゾルバーlibがインストールされます。 たとえば、libsolv + pip固有のPythonバインディングの正確なパッケージを固定し、説明したように、boostrap-pipからそれらをインストールできます。 それは私には完全に実行可能に聞こえますが、何が関係するかをもっとよく知っているかもしれません...

追加のプラットフォームサポートを実現するのはそれほど難しいことではないと思います

明確にするために、私はよりニッチなプラットフォームに既得権を持っていません。pipがサポートされているプラ​​ットフォーム（現時点では基本的に「Pythonを実行できるもの」）に影響を与えるかどうかを非常に明確にする必要があると思います。 ）。 C拡張機能をどのように出荷するかという展開の問題もあります（pipは現在「ユニバーサル」ホイールとして出荷されているため、 get-pip.pyなどの一部のユースケースでは重要です）。

ブートストラップについては、現在のメカニズムを使用して解決する純粋なPythonpipを使用できると思います

私は上で議論しました、そして私はここでそれを繰り返します、私は本当にピップで2つのリゾルバーを無期限に維持する必要はありません。

しかし、私は提案についてあまり否定的になりたくありません-あなたが気づいていない場合に備えて、現在C拡張機能への依存を許可していない理由のいくつかにフラグを立てたいと思いました。

議論はおそらく他の場所に適していて、詳細が明らかになった場合は完全に冗長になる可能性がありますが、私は今、私の質問を本当に出したいと思います。

私の理解では、libsolvは依存関係の解決に完全なSATソルバーを使用しており、解決を開始する前にまず依存関係情報をロードする必要があります。 ただし、現在のPyPIは、パッケージごとに依存関係のメタデータを格納しています。 setup.pyの実行時間に依存する性質を無視しても、SATソルバーに必要な情報を効率的に取得することは困難です。

この問題をどのように処理する予定ですか？ パッケージのアップロード時に.solvファイルを生成するためのインフラストラクチャを実装する（およびサードパーティのリポジトリ実装の追加仕様を提案する）予定はありますか？ または、ソルバーが進むにつれて適切な解決可能なデータを生成するための戦略があり、新しい依存関係データが入ってくるときにバックトラックを実装する可能性がありますか？

私はこの点に関する既存の作業を認識していません。私が見つけることができるほとんどのリソースは、PythonパッケージングランドスケープがストレートアップSATソルバー以上のものを必要としていることを示唆しています。 だから私はここでどんな可能性にも非常に興味があります。

これらの.solvファイルはキャッシュ用であり、libsolvは解決のためにそれらを必要としません。 しかし、PyPIの依存関係の動的な性質により、SATソルバーの使用が困難になることに同意します。

（詳細については、https：//docs.google.com/document/d/1x_VrNtXCup75qA3glDd2fQOB2TakldwjKZ6pXaAjAfg/editを参照してください）

（SATソルバーは、競合が発生した場合に句の学習も行う単なるバックトラッキングソルバーであるため、PyPIにSATソルバーを使用することは可能だと思います。ただし、句を動的に追加できるソルバーである必要があります。解決しながら。）

土ソルバーには、動的追加、再起動、バックトラック、ランダム再起動など、最近いくつかの重要な機能があります。しかし、ここでの課題は、構築できる保証がないプラットフォームをサポートする必要性に関連する技術的な課題になると思います。 Cベースのソルバー。

私は今空港にいるので、今提起されたポイントに答えることはできませんが...ここで技術的な選択/トレードオフについて議論するべきではないと確信しています-これはより範囲が広いですロールアウトとロールアウトのコミュニケーションと管理の方法。 :)

技術的なトレードオフについてさらに議論するために＃7406を提出しました- @ sdispater 、 @ techalchemy 、 @ uranusjr 、@ wolfvリゾルバー設計のさまざまな選択についてさらに議論できれば幸いです。

早い段階で期待を設定するために、私は次の2週間旅行するつもりであり、うまくいけば、12月9日までのすべての議論に追いつくことができるでしょう。

ステータスの更新：PSFは、MozillaオープンソースサポートとChan Zuckerberg Initiativeから資金を調達して、pipリゾルバーと関連するユーザーエクスペリエンスの問題に取り組む請負業者を雇うことができました。 私たちのロードマップ（私が磨く必要があります）とブログとフォーラム、そして最近の会議からのメーリングリストの投稿とメモを見て、通知を続けることができます。 これについては、すぐにdistutils-sigとPythonのDiscourseインスタンスのPackagingフォーラムに投稿する予定です。

7月のpip20.2でのリリースに向けて、pipのリゾルバー機能を準備することを目指しています。 （ピップの四半期リリースケイデンスごとに、予期しない問題が次の四半期の20.3まで遅れる可能性があります。）

@uranusjr ：

私の理解では、libsolvは依存関係の解決に完全なSATソルバーを使用しており、解決を開始する前にまず依存関係情報をロードする必要があります。 ただし、現在のPyPIは、パッケージごとに依存関係のメタデータを格納しています。 setup.pyの実行時間に依存する性質を無視しても、SATソルバーに必要な情報を効率的に取得することは困難です。

＃7819のプロトタイプpip resolveコマンドは、2つの手法を使用して、この情報をパフォーマンス的に取得します（詳細については、その問題を参照してください）。

1. >実際にホイールをダウンロードせずに、ホイールのURLからMETADATAファイルの内容を抽出します。
2. >各self._resolve_one（）呼び出しの結果を永続的なjsonファイルにキャッシュします。

（1）で使用される手法は、ホイールのコンテンツ自体の数KBのみをダウンロードしながら、ホイールのURLを非常に迅速に依存する要件文字列のリストに変換することができます。 次に、＃7819のプロトタイプは、 self._resolve_one()によって返される依存要件ごとにreq.populate_link()が呼び出されるようにし、 (==Requirement, url) -> [list of (==Requirement, url) non-transitive dependencies]のマッピングを永続的なjsonキャッシュファイルに保存します。 （1）新しい情報をすばやく取得し、（2）古い情報のクエリを高速化します。

私はまだlibsolvに精通していませんが、要件URLから依存関係へのこのマッピングのエントリとそれらのURLは、SATソルバーに必要なアトミック入力とまったく同じである可能性があります。 ＃7189に示されているように、永続的なjson依存関係キャッシュファイルにより、最初の実行後にpip resolveの呼び出しが完全にノーオペレーションになり、それ以降はコマンドラインで800〜900ミリ秒かかります。 （1）と（2）の手法を使えば、信じられないほど長い時間を待たずに、pipが呼び出されるたびにSATソルバーを実行して完了することができると思います。 この数をより具体的にするために、＃7189のプロトタイプの上でlibsolvをハッキングすることを試みるのはおそらくそれほど難しいことではないでしょう。

@techalchemy ：

土ソルバーには、動的追加、再起動、バックトラック、ランダム再起動など、最近いくつかの重要な機能があります。しかし、ここでの課題は、構築できる保証がないプラットフォームをサポートする必要性に関連する技術的な課題になると思います。 Cベースのソルバー。

以前は、コンパイラとリンカーをsetup.pyベースのプロジェクト（＃ 6273 ）に簡単に公開できるコードが含まれていましたが、ビルドを可能にするために、後でこれを削除しました（＃7016を参照）。 setup.pyを使用しないパンツのC / C ++。これは、 TensorFlowカスタム演算子の共有ライブラリを構築するだけでよいTwitter内のユースケースに適していました。 静的にリンクされたGCCおよびbinutilsアーカイブ用のビルド済みバイナリをOSXおよびLinux用のs3でホストし（https://github.com/pantsbuild/binaries/を参照）、パンツユーザーがPythonとJDK以外のものをインストールする必要がないようにします。パンツを使うのに。

サポートされているすべてのプラットフォームでpipがlibsolvに確実に依存できるようにする、CおよびC ++を移植可能に構築するためのあらゆるタイプのツールのブレインストーミングおよび/または開発を支援することに興味があります。

@cosmicexplorer

以前は、コンパイラとリンカーをsetup.pyベースのプロジェクト（＃6273）に公開しやすくするコードが含まれていましたが、C / C ++のビルドを可能にするために、後でこれを削除しました（＃7016を参照）。 setup.pyを使用せずに、TensorFlowカスタム演算子の共有ライブラリを構築するだけでよいTwitter内のユースケースに適していました。 OSXおよびLinux用のs3で静的にリンクされたGCCおよびbinutilsアーカイブ用のビルド済みバイナリをホストします（pantsbuild / binaryを参照）。これにより、パンツユーザーはpythonとJDK以外のものをインストールしてパンツを使用する必要がなくなります。

コンパイラ/リンカーの作業は非常に興味深いものです。 コンパイラをsetup.py（または一般にPEP 517ビルドバックエンド）から分離することについての議論もあります。 これは実際にはリゾルバーとは関係ありませんが（少なくとも直接ではありません）、興味があるかもしれません： https ：//discuss.python.org/t/how-do-we-get-out-of-the-business-of-

@cosmicexplorer

サポートされているすべてのプラットフォームでpipがlibsolvに確実に依存できるようにする、CおよびC ++を移植可能に構築するためのあらゆるタイプのツールのブレインストーミングおよび/または開発を支援することに興味があります。

私自身と@wolfvは、マンバでサポートされているすべての主要なプラットフォームでDNFパッケージマネージャースタックの一部を構築するためにこれを検討しており、DNFでの私自身の個人的な作業も行っています。 この時点で、libsolvはWindows、Linux、macOS、BSD、Haiku OS向けに構築できるようになりました。私は、UNIXでDNFを使用する一環として、さまざまなUNIXシステムにlibsolvが配置されていることを漠然と認識しています。 @dralleyは、PyPI manylinux2014を使用して、PyPI〜Linuxでサポートされる〜主要なプラットフォームでsolvバイナリホイールを利用できるようにしたことも知っています。

現在、pip 20.1b1がリリースされています。これは、新しいリゾルバーの非常に初期の（アルファ）バージョンを含むベータリリースです（そのコンテキストと、人々がフィードバックを提供できる調査については、＃8099を参照してください）。 これが発表です。 また、 https： //github.com/pypa/pip/issues/7951#issuecomment -617851381には、これまでにベータ版を公開した場所がいくつか記載されています。

pip 20.1がリリースされ、リゾルバーのアルファバージョンが含まれています。

5月に別のpipリリースを公開することを検討しています。これには、リゾルバーのさらにアルファ版が含まれています。 そして、新しいリゾルバーのベータ版をいつリリースし、「これをテストしてください」というプッシュをいつ行うかを考えています。

＃8371、特定のエラーメッセージをより適切に表示する方法、および他の多くの厄介なものを処理する方法を理解しているときに、遅延が発生しました。 進捗状況の詳細については、 https：//github.com/pypa/pip/projects/6およびhttps://github.com/pypa/pip/projects/5を参照してください。 ＃8206は、次のベータ版であるpip 20.2b2についてのディスカッションです。これは、6月末までに公開できることを願っています。

PSFブログに年央報告を掲載しました。 知っておくべき重要なことの1つは、今月後半にpip 20.2をリリースする予定です。これには、オプションのフラグ「 --use-feature=2020-resolver 」を介して利用できる新しい依存関係リゾルバーのベータバージョン（pip 20.1にはアルファバージョンがあります）があります。 私たちはpip20.2をたくさん公表し、多くのユーザーに新しいリゾルバーをそのペースに乗せるように依頼します。

＃8511に従って、 pip20.2をリリースしました。 このリリースには、次世代の依存関係リゾルバーのベータ版が含まれています。 互換性のない命令を受信すると、大幅に厳密で一貫性が高まり、特定の種類の制約ファイルのサポートが減少するため、一部の回避策とワークフローが機能しなくなる可能性があります。 --use-feature=2020-resolverフラグを使用してテストしてください。 テストと移行の方法、および問題の報告方法については、ガイドをご覧ください。 新しい依存関係リゾルバーは、日常的に使用する準備がまだ整っていないため、デフォルトではオフになっています。

2020年10月にpipの次の四半期リリースである20.3を作成する予定です。デフォルトの依存関係解決動作を変更し、新しいリゾルバーをpip20.3のデフォルトにする準備をしています。

このブログ投稿をポイントして、この言葉を広めてください。HackerNews、Reddit、Twitter、Facebook、Dev.to、Telegram、関連するStack Overflowの回答、お気に入りのSlacks andDiscordsに広めてください。 これが影響する人々のほとんどは、Python固有の開発者ニュースに追いついていない。 10月までにヘッズアップを取得し、バグレポートを取得するのを手伝ってください。

（私のメモを＃988からコピーします。）

@zoobaは尋ねました：

この段階で（最初のRCの場合）Python 3.9にバンドルされているpipのバージョンを更新する必要があると思いますか？

同様に、次のリリースのためにPython 3.8を更新する必要がありますか？

私の仮定では、はい、来週初めのバグ修正リリースの後、はい、しかし@pfmoore @xavfernandez @cjerdonek @uranusjr @pradyunsg @dstufftどう思いますか？

申し訳ありませんが、投稿を早すぎます。 私の考えでは、pip 20.2をバンドルすると、経験豊富な開発者がPythonの最新バージョンをテストしながら、新しい依存関係リゾルバーを簡単にテストできるようになります。 しかし、そのバンドルされたバージョンを更新するのにどれだけの作業が必要か、またはどのくらいの頻度で更新したいかはわかりません。

ここでも同じですが、新しいリゾルバーに簡単にアクセスできるように、3.9に20.2.xを含めると便利です。

どう思いますか？

あなたは正しいです、それは計画です。 :)

OK、 python-devで回答しました-はい、Python3.8および3.9にバンドルされているpipのバージョンを20.2.xに更新する必要があります。

これとは別に、宣伝に関して、ここで進行中の作業に注意します。

今後6〜8週間は、ユーザーが新しいピップを試してみることができるように、広く宣伝することを推進します。 問題は「この個別のパッケージがインストールされない」ということではないと思います。 おそらく環境や特定の制約ファイルに応じて、特定のパッケージ間で予期しない競合が発生する可能性があります。 バグを修正したり、より自動化されたテストを設定したりできるように、またそれらのアップストリームパッケージがヘッドアップを取得してpip 20.3の前に修正済みパッケージをプッシュできるように、調査を通じて早期のフィードバックを取得しようとしています（例：https：//github.com/pypa/pip/issues/8076#issuecomment-666493069のTensorFlow / numpy / scipyの問題）。

これにどれだけ努力しても、20.3につまずく不整合に対処するユーザーがいて、彼らは欲求不満で混乱して傷つき、それが私たちとそのすべての上流のサポート負荷を引き起こします。 ユーザーにテストを依頼し、アップストリームの注目を集めることで、これを減らすことを目指しています。

そのため、データサイエンティスト、教師、アーティスト、DevOpsスペシャリストなど、特定のドメイン固有のコーナーに注意を払っているグループに連絡して活用する予定です。

私は、彼らの注意を引く1つの方法は、彼らが依存している特定のパッケージを介することであると仮定します。

昨日、広く使用されているパッケージのリストをいくつか調べ、数人に手動でメールを送信し、いくつかのリポジトリで問題を作成して、ユーザーに新しいリゾルバーのベータ版でテストし、ボールを転がして試してみるように依頼することを提案しました。いくつかの宣伝とテストを得るための文言/アプローチ。 これにより、少なくとも1つのケースで混乱が生じました（https://github.com/sqlalchemy/mako/issues/322#issuecomment-667546739を参照）。20.2のバグ修正リリースがリリースされたら、もう少し詳しく説明します。体系的かつ明確

• なぜ私たちが手を差し伸べているのか
• 連絡先/連絡先（パブリックメディア戦略へのリンクが役立ちます）
• 自動テストを使用してこれらの問題を自分で見つけることができない理由

Twitter（ 1、2 ）とReddit （ PyPAの資金調達に関するこの質問に回答したい人はいますか？）で少し注目を集めています。

@zoobaは書いた（バンドルに関して）：

ありがとう。 今週後半にそれを実行して、次のラウンドのリリースを行うことができるようです。 解放されたくないことがあれば、できるだけ早くお知らせください。

私の--use-feature=2020-resolverは、一般的に、それが引き起こすよりも多くの問題を修正していることがわかります。

次の方法で最初の展開を提案するには遅すぎますか？

提案された20.3擬似コード

try:
    _2020_resolver()
except:
    legacy_resolver()

これは、少なくとも私のプロジェクトでは、すべて変更なしで合格することを意味します

その後、レガシーリゾルバーがデフォルトで無効になったら、しばらくの間、2020リゾルバーで動作するプロジェクトと、レガシーリゾルバーで動作しないプロジェクトがある可能性があります。フォールバックを有効にするために、1つのフラグを設定できるようにしたいと思います。

提案された20.4擬似コード

try:
    _2020_resolver()
except:
    if not use_legacy_resolver:
        raise
    legacy_resolver()

今月中に20.3を展開する予定です。 混乱しているユーザーからの質問があるため、これには大量のユーザーサポートが必要になると予想されます。

@diは、最初の対応を支援するために何人かのボランティアを集めるのを手伝うことを志願しました。 これらのボランティアは、Twitter、StackOverflow、GitHubで新しいピップがリリースされたら、質問に答えてユーザーサポートの読み込みを支援し、実際のバグをメンテナー/コントリビューターチームの注意を引くようにエスカレーションします。

ダスティン、これがどのように機能するかについて大まかな計画があると思います。ここに投稿していただければ、他のピップメンテナーからコンセンサスを得ることができますか？ どうもありがとうございました。

これが私の大まかな計画です：

• サポートを求めるdiscuss.python.orgでディスカッションを開始します
• 全員の間のコミュニケーションチャネルとして機能する可能性のあるSlackチャネルに人々を誘導します
• いくつかのFAQと回答の概要を説明するドキュメントを開始します
• 新しい問題の決定木を含める->トリアージされた問題
• リリース日がわかったら、これをチャンネルと共有します
• リリース後の数日間に、ボランティアがオンラインでトリアージするように大まかにスケジュールしてみてください

ありがとう、@ di。 明日まで他のメンテナからOKをもらうのを待っています。 そして、10月28日または29日の水曜日または木曜日にpip20.3をリリースすることを目指しています。

@diあなたの計画が承認されたようです。 先に進んでください！

@diは、リリースの遅延の可能性について注意を促します。

20.3を公開できるときに私が不在の場合（来週になることを願っています）、ここに宣伝計画があります。

他の場所のコメントで説明したように、 CIの問題が発生し、外部要因が原因で、リリースを少し遅らせることにしました。

今日のチームミーティングでは、20.3のリリースが明日または金曜日になる可能性があることに同意しました。 詳細については、＃8936をフォローしてください。

以前のコメントで提案したほど、パッケージごとのアウトリーチは行いませんでした。 しかし、それは私たちがアウトリーチをしなかったことを意味するものではありません。 私たちが行ったアウトリーチのいくつか（そのうちのいくつかは＃8511またはこのwikiページにカタログ化されています）：

• ポッドキャスト： Podcast.__init__ 、テストとコード、 FLOSS Weekly 、ソフトウェア開発者の旅、 Real Python
• たくさんのツイート
• 変更についての短いYouTubeビデオ
• PSFスポンサーシップの連絡先からPyCon、PSF、およびPyPIスポンサーに電子メールを送信し、エンジニアリング部門に今後の変更について通知するように依頼します。
• pypi-announceおよび同様のリストへの電子メール
• このようなブログ投稿
• シビックテックおよび同様のグループ/シンクタンクへの電子メール

過去数か月間、20.2および20.3ベータ版のpip 20.3b1で新しいリゾルバーをテストしている人々から、新しい問題が次々と発生しています。 これらのレポートは、リゾルバーを改善し、バグを修正し、その出力のUXを改善するのに役立ちました。 また、ベータ版のフィードバックに一部対応して、 「変更点」のユーザーガイドを大幅に改善しました。

これが私の大まかな計画です：

* Start a discussion on discuss.python.org asking for support

* Direct folks to a Slack channel that could serve as a communication channel between everyone

* Start a document outlining some FAQ and our responses

* Include a decision tree for new issue -> triaged issue

* Share this with the channel once we have a known release date

* Try and roughly schedule volunteers to be online & triaging in the days following the release

@di絶え間ない不確実性と遅延により、おそらくスケジューリングを実行できなくなっていることを認識しています。 新しいリリース日は明日、11月30日月曜日です。 共有するディスカッションスレッドと決定木がある場合は、先に進んで共有してください。

pip 20.3がリリースされ、デフォルトで新しいリゾルバーが追加されました。 PSFブログでのリリースの発表は次のとおりです： https ：//blog.python.org/2020/11/pip-20-3-release-new-resolver.html