4799は、多くの議論が行われている場所です。 それは主に次のことによって促されました：

1. PEP 518サポートの唯一の優れたブロッカーは＃4764（https://github.com/pypa/pip/pull/4144#issuecomment-302711736経由）であることを理解しました
2. それから＃4799が出てきて、それを見て、 @ xoviatが行っていた進行中のすべての作業を理解できるかどうかを確認しました。
3. その過程で、＃4647がリリースブロッカーとしてポップアップし、PEP518のサポートが壊れたことを示しました。

@xoviatが＃ 4799で言っていることを理解しようと掘り下げてみると、ビルド環境の再帰的なビルドに関していくつかの問題があることが明らかになりました（XはビルドするためにYが必要であり、YはZが必要です...）。 mこれらが実装のバグなのか、より深い設計上の問題なのか、それともあまり問題なく延期できる厄介なコーナーケースなのかはまだ不明です。

個人的に、私は自分の深みから外れているところにいます。 @xoviatの実装が必要かどうか、または＃4764をマージして＃4647を修正して準備ができているかどうかを判断するための実装がわかりません。 また、＃4647を修正するのがどれほど簡単かわかりません（ @xoviatは、＃4647を修正するために＃4799をマージする必要があると言っているようですが、それ自体に問題があります）。

私は今週末、議論をさらに進めるための時間とエネルギーを使い果たしたので、この時点で（少なくともしばらくの間）中退するつもりです。 私にとって重要なのは、ピップ10に対して許容レベルのPEP 518サポートが必要なことです。誰かに、私たちがもうすぐそこにいるのか、それとも数週間先にいるのかを感じてもらいたいのです。ピップ10が来て、新年まではないと言うだけで人々が興奮するのを避けることができます...

非常に役立つ要約@pfmooreをありがとう。

@ncoghlan @dstufft @xoviatここで議論をしていただけませんか？ クローズドPRでそれを行うことは私には奇妙に感じます。 ._。

確実なこと。

@pradyunsg私はあなたがこれのための時間がないことを知っています。 しかし、あなたは私よりもPRの承認を得ることに成功しているので、必要に応じて、現在の実装、その仕組み、および潜在的な問題について説明します。 これらの問題の一部（すべてではない）をどのように解決したか、および完全に修正するためのアイデアについて説明します（これも、PEP 517の後で、完了していない場合は実行できます）。 私は正直なところ、それが行われている限り、誰がその仕事をするかは気にしません。

実際、あなたはAWOLなので、要約を書かせてください。

pipには、ほとんどのPythonプロジェクトで一般的なオブジェクト階層があります。 それはすべて、オブジェクトへの新しい参照を作成するコマンドを開始し、下位のオブジェクトへの新しい参照を作成します。 それは木のようなものです。

オブジェクトの「スコープ」を一種のライフタイムとして定義します。 オブジェクトが存在する期間です。 現在、 pipのPEP 518のスコープはWheelBuilderです。 PEP518環境はbdist_wheelに設定され、次にbdist_wheelがその環境内で実行され、次に環境が破棄されます。

それで、それの問題は何ですか？ 問題は、PEP 518環境のスコープが、 setup.pyへのすべての呼び出しのスコープ以上である必要があることです。 具体的には、 setup.pyの呼び出し中に存在するオブジェクトをカプセル化する必要があります。 そのオブジェクトはRequirementです。

あなたが遭遇する最初の明白な決定は次のとおりです： BuildEnvironmentへの参照を持つべきもの、そしてRequirementは他の場所として良い場所です。 実際、 Requirementが存在する場合にのみ、 setup.pyが呼び出されるため、IMHOが参照を配置するのに最適な場所です。

次に発生する可能性のある問題は次のとおりです。 BuildEnvironment要件をどのようにインストールしますか？ pipまでシェルアウトすることができます。 そして、それは元の実装者によってなされた決定です。 ただし、これには問題があります。 pipは、各pipが再び自分自身を呼び出す可能性があるため、シェル呼び出しがいくつ行われているかを知る方法がありません。 実際、循環依存関係を持つ悪意を持って構築されたパッケージは、 pipが生成するプロセスが多すぎると、誰かのコンピューターをクラッシュさせる可能性があります。

もう1つの問題は、どのシェル呼び出しを行う必要があるかということです。 コマンドラインパラメータを取得することは、率直に言って、その呼び出しを行う必要があるPITAであるため、実際には想像以上に注意が必要です。 そのため、ユーザーが子に渡した元のパラメーターを渡すのに問題が発生する可能性があります。 元の実装者が使用したソリューションにはfinderの使用が含まれていましたが、問題はご存知だと思います。

ユーザーがctrl + Cを押したときに子を殺すことができる、ある種のマネージャークラスなしで自分の子をシェルアウトすることは、間違っているだけでなく、特に、生成したプロセスの数がわからない場合は悪意があります。 私は個人的に、子供たちが現在の実装で死ぬかどうかはわかりません（これはFUDかもしれません）が、そうでない場合、現在の実装IMHOは間違っています（他の懸念は別として）。

その問題に対するいくつかの可能な解決策は次のとおりです。

1. PEP 518をドアの外に出したい場合、最善の策は、ピップが無限に増加しないようにするために、最大10個程度のロックしか許可しないある種のロックファイルです。 次に、コマンドライン引数とともに正確な要件を子に渡すことができます。

2. PEP 517の後に実装したい適切な解決策は、 installコマンドで直接初期化されるBuildEnvironmentManagerクラスを用意することです。 BuildEnvironmentManagerには、そこにあるすべてのオブジェクト（ RequirementPreparer 、 WheelBuilderなど）への参照があり、単一のメソッドget_build_environment(requirement_set)があります。 次に、 RequirementPreparerにset_build_environment_managerのようなメソッドを実装し、それを使用してビルド環境を取得できます。 BuildEnvironmentManagerは、同じ環境（最も一般的に['setuptools', 'wheel'] ）の複数の使用を検出し、複数回必要な場合は同じ環境を提供して、作成する必要がないようにすることもできます（最初は非常に一般的です）。 pyproject.tomlがないプロジェクトの場合）。 理想的には、循環参照を削除しようとするOOP設計もあります（簡単ではありません）。

@xoviat意図的な悪意のあるケースをカバーしていないかもしれませんが--no-binary :all:完了したビルドだけでなく、 -進行中のものは、ビルド依存関係サイクルを確実に終了させるのに十分でしょうか？ これは、最初の提案（同時ピップ呼び出しの数に対するクロスプロセス制限）の変形ですが、次のように再定式化されます。

1. マシン上の1つのプロセスのみが、同時に同じパッケージを構築することが許可されています
2. 生成するサブビルドにpipが渡すトップレベルの「ビルドID」があります（たとえば、ビルドされるパッケージの名前と組み合わされたトップレベルプロセスのPID）
3. ビルドキャッシュが、何かが別のビルドIDでビルドされていることを示している場合は、そのビルドが完了するのを待ちます
4. ビルドキャッシュが、同じビルドIDに対して何かがすでにビルドされていることを示している場合は、循環依存関係を報告し、ビルドが機能するために--binary <name>が必要になることを示すエラーでベイルアウトします。

pipは、 setuptoolsとwheelの両方を必要とするデフォルトロジックからsetuptoolsとwheelを免除するという@pfmooreの提案も実装する必要があります。 wheelをビルドの依存関係として使用します。そうしないと、暗黙的なビルドの依存性の注入により、本質的に循環依存性の検出ロジックがトリガーされます。

ディスクを使用してOOP設計の問題を理解する必要がないようにすることは、悪い考えではありません。 これは、PEP 518を完全に正しく実装することと、何かを一緒にハッキングすることの間の中間オプションのようなものです。

また、オペレーティングシステムレベルのツールを使用してさまざまなPythonレベルのビルドを互いに分離しておくことができるため、コンテナ化された環境やchrootとうまく相互作用するため、pipは独自のサブプロセスを確保する方法を理解する必要があります。互いに協力する。

@xoviat上記の要約に感謝します。 私が言ったように、私はこの分野のコードの理解の限界に達しました、そしてあなたの説明は私を大いに助けてくれました。

私は実際に＃4144のコードを見たことがありませんでした。 私はちょうどしました、そして、私はそれが出荷されることを本当に望んでいません。

PEP 518を完全に正しく実装し、何かを一緒にハッキングするだけです。

正直なところ、これに帰着すると思います。 PEP 518を完全かつ適切に実装することは、そのようにすれば、ピップ10を（公正な）ビット遅延させる/可能性のあるタスクです。

ここでの安全な中間点は、ビルド依存関係をホイールとして使用できるようにすることを要求することだと思います。 そうすれば、ビルドの依存関係（およびそれらのすべての依存関係）をこのプロセスでビルドする必要がないため、再帰の問題を回避できます。

これはどのように聞こえますか？

制限されていますが、制限された最初の実装は、注意を怠った場合に自分で撃つことができる最初の実装よりも優れていると思います。

PEP 518を完全かつ適切に実装することは、そのようにすれば、ピップ10を（公正な）ビット遅延させる/可能性のあるタスクです。

それを確認してくれてありがとう-それは私の恐れでした。

しかし、少なくとも部分的なPEP 518がすでにマスターになっていると思ったので、今は混乱しています。 具体的には、私が理解しているように、＃4647はマスターでのPEP 518サポートのバグを示しています-それが正しくないので、明らかに私たちはすでに何かを持っています...

だから私たちは何かをしなければなりません、そしてそれはオプションが次のように思われます：

1. 現在PEP518サポートのために持っているものは何でも取り除いてください。
2. 私たちが持っているものを片付けて、部分的なサポートを出荷します。
3. pip 10をリリースする前に、PEP518を完全に実装してください。

あなたが言うように、（3）はpip 10の前に長い遅延を意味し、私が本当にリリースしてほしい他の修正があります（Unicodeの修正は私たちが定期的に問題を抱えているものです）。 だから私はそれに熱心ではありません。 （1）についてはおっしゃっていませんでしたが、それはPEP 518のサポートがないと思っていたのか、それとも取り消すことができないと思っていたのかはわかりません。 個人的には、このアイデアは好きではありません。これは後戻りのステップであり、正しく実装するのが難しい場合は、PEP自体についてかなり否定的なメッセージを送信します。 しかし、私たちはそれを拒否することについて明確にすべきだと思います。

ビルド依存関係としてホイールのみをサポートするバージョンのPEP518を出荷するという（2）の提案（ホイールであるビルド依存関係を使用するデモンストレーションとして、＃4647を修正する必要があります）は妥当なようです、実装するのが実用的であるという意味で。 私の主な予約は、PEP518を使用したい人にとってその制限がどれほど問題になるかわからないということです。

ですから、私たちは何をしても行き詰まっているように感じますが、ビルドの依存関係としてホイールのみをカバーする部分的なサポートは、悪いロットの中から最良のオプションです:-(

PEPの作成者（https://github.com/pypa/pip/pull/4799#issuecomment-338331267およびhttps://github.com/pypa/pip/pull/4799#issuecomment-338332575） https://github.com/pypa/pip/pull/4799#issuecomment-338325354）は、完全なPEPサポートにはビルドの依存関係を構築する必要があることを明確に示していたため、一時的なものである必要があります。

しかし、これを実装するのは私ではないので、誰が実行するかを判断して喜んでいます。 私が行ったことの1つは、＃4803を作成し、リリースブロッカーとしてマークすることです。必要に応じて、仕様からどのように逸脱するかを文書化する必要があることを思い出させてください。

（そしてこの問題についてはトピックから外れていますが、PEP 517の実装を開始するときに同じ間違いをしないように注意することをお勧めしますか？コーディングに深く入り込む前に、実装の影響をすべて理解していることを確認しましょう-私の本能PEP517はPEP518よりもさらに複雑な設計上の問題になるということです...）

「ソースからすべてをビルドする」という観点からは、ディストリビューションに最も精通しており、「ビルドルートのブートストラップ」プロセスを通常のパッケージビルドのプロセスから確実に分離しています。 Cコンパイラのブートストラップなどを行う必要があるため、ソースからの完全な自動ブートストラップは困難です。

したがって、pipの場合、ビルドの依存関係は常にホイールファイルからインストール可能であると言うのが妥当だと思います。 10.x以降に導入できる改良点は、通常のホイールキャッシュとは異なるビルドキャッシュを用意することです。これにより、キャッシュのユーザーは、PyPIからダウンロードするのではなく、制御された環境ですべてのホイールがビルドされたことを確認できます。または別のインデックスサーバー。

個人的には、このアイデアは好きではありません。これは後戻りのステップであり、正しく実装するのが難しい場合は、PEP自体についてかなり否定的なメッセージを送信します。

私は必ずしもそれに同意しません。 pipを正しく実装するのは難しいです。 しかし、PEPに記載されているpipは、人々が使用する唯一のフロントエンドの1つです。 言語実装者としての私たちの仕事だと思います。pipは実際には、Pythonプロジェクトをパッケージ化するために使用する言語であり、これらの難しい問題をすべて考えることなく、ビルドシステムをできるだけ簡単に作成できるようにします。 彼らにとっては、私たちが大変な仕事をしたので、それはシームレスに機能するはずです。

ここでの安全な中間点は、ビルド依存関係をホイールとして使用できるようにすることを要求することだと思います。

実際、それはまさに＃4799が行うことです。 必要に応じて、そのブランチを復元してから、フォークしてPRとして送信できます。

@xoviatが上で指摘したように、（2）の実装側の2つのことはまだ残っています：

1. サブプロセスを作成する方法を理解する（引数など）
   私は実行可能であるべきだと思います。

2. インストールするパッケージバージョン。
   現在のリゾルバーコードがまだpip._internal.operations.prepareのコードと絡み合っているという事実を考えると、これがどのように正確に行われるかはわかりませんが、これはおそらく同じ親プロセスで実行する必要があります。 今週中にこれを調べます。

しかし、誰がこれらを行う時間があるのか​​わかりません。

正しく実装するのが難しい場合は、PEP自体についてかなり否定的なメッセージを送信します。

正しく実装するのはおそらく難しいことではありません。 今日のpipのコードベースのように、pipに実装するのは簡単ではありません。奇妙な場所で発生することがあり、それがクリーンアップされれば、かなり簡単になると思います。

（1）についてはおっしゃっていませんでしたが、それはPEP 518のサポートがないと思っていたのか、それとも取り消すことができないと思っていたのかはわかりません。

バックアウトはオプションではないと思いました。

今考えてみると、PEP518をpip10で出荷することはどれほど重要ですか？ 次のメジャーリリースまで延期できれば、（この状況から簡単に抜け出す以外に）簡単で、517 +518の両方が1つの大きなリリースに到達する可能性があると思います。 これは十分にきれいに感じられるので、私はこれが進むべき道ではないと言う人にはなりません。

@dstufft @xavfernandez考え？

@ncoghlanのビルドキャッシュのアイデアは、私には良いアイデアのように思えますが、そのすべての意味を理解しているとは言えません。

必要に応じて、そのブランチを復元してから、フォークしてPRとして送信できます。

おそらく時間がないでしょうし、時間があったとしても、既存のコミットを再利用していない可能性があります。 しかし、そのブランチを復元しても問題はありません。 :)

私の主な予約は、PEP518を使用したい人にとってその制限がどれほど問題になるかわからないということです。

あなたがおそらくそれを知らなかったことを除いて、私たちはこの正確な議論をしました。 このシチュエーションはシチュエーションXです。ビルド環境がセットアップされる前にegg_infoを呼び出すのは、シチュエーションY（＃4799）です。

しかし、これを実装するのは私ではないので、誰が実行するかを判断して喜んでいます。

それは＃4799がテーブルに戻ったことを意味すると思いますか？ それがすべてのテストに合格し、それが行うと主張していることを実行する限り？

ああ、それらのXとYは再び私を悩ませるために戻ってきます：wink：はい、私は2つのケースの相対的な可能性についての感覚がないと言っています。 ホイールではないビルド要件は非常にまれであるため、そのケースを無視しても問題ないとおっしゃっています。 基本的に、私たちの間で「大丈夫」と「わからない」の投票が1つずつありました。 私はこのオプションをブロックしようとはしていません。私の直感の限界がどこにあるかを言っているだけです。

@xoviatいくつか質問があります。 あなたが新しいPRをする前にあなたがそれらに答えるならば、それは素晴らしいでしょう。 :)

• どのパッケージがインストールされるかをどのように判断しますか？
• バイナリのみのビルド依存関係に制限しますか？

私は多くの科学プロジェクトに携わってきたので、偏見があるかもしれません。 しかし、ホイールビルドの依存関係を持つプロジェクトのリストをガラガラと鳴らすことはできますし、ソースの依存関係を持つ1つのプロジェクトを本当に考えることはできません。 たぶん私は間違っています。

@rgommers PEP 518は、次のピップにある場合にホイールとして利用可能なビルド依存関係のみをサポートしても大丈夫ですか？

どのパッケージがインストールされるかをどのように判断しますか？

サブプロセスは、指定されたとおりに要件リストを取得します。 そうすれば、リゾルバーを通過します。

バイナリのみのビルド依存関係に制限しますか？

はい、それが実際にテストが失敗した理由です。 テストのビルド依存関係はホイールではありません。

今考えてみると、PEP518をpip10で出荷することはどれほど重要ですか？ 次のメジャーリリースまで延期できれば、（この状況から簡単に抜け出す以外に）簡単で、517 +518の両方が1つの大きなリリースに到達する可能性があると思います。 これは十分にきれいに感じられるので、私はこれが進むべき道ではないと言う人にはなりません。

ピップ11のPEP517と518を行う時間のある人がいるかどうかについて、私たちはどのように感じていますか？ 私は楽観的ではありません。 どちらも大きな作業の塊であるように思われます。また、リゾルバーの作業も進行中です。 私はピップ10を必要以上に長く保持することに賛成ではありませんが、一連の本質的にマイナーなリリースをリリースする間、主要な機能計画のすべてをドリフトさせることにも同様に不快です。

言い換えれば、「ピップ10のリリースに行こう」と言うと、PEP518の作業が復活しました。 それをpip10から削除すると、私はリリースの準備に集中することになり、PEP518が再び勢いを失う可能性が高いと思います。 物事を再び活動に移すにはどうすればよいですか？ @xoviatは実装に取り​​組んでいますが、これまで苦労してきた問題を他の人に理解してもらうのに問題がありました。 二度とフィードバックなしで彼を働かせたままにしたくありません。

私たちにできることは、準備が整ったインクリメンタル修正だけで「pip 9.1」をリリースし、パイプラインにある3つのビッグチケット機能（の少なくとも1つ）の実装用にバージョン番号「pip10」を予約することです。 しかし、そうするなら、2018年の第1四半期にpip10のリリースを約束することを試みたいと思います[1]。アプローチとしてはそれで大丈夫です。 しかし、私たちが現在マスターで持っている部分的なサポートを取り消すのに何が関係するのか、誰かが感じていますか？ または、私たちが持っているものとその制限を文書化する際に（人々がそれが完全であると仮定してそれを使用しようとしないように、バグを見つけて、「この機能はまだ完全ではありません、申し訳ありませんが、ピップを待つ」で対応しなければならない問題を提起します10 "）？ ある大きな作業を別の作業と交換しているだけですか？

[1]私たちが利用できるすべてのものとして、非常に限られたボランティアリソースで何にでもコミットできる範囲で。

私は多くの科学プロジェクトに携わってきたので、偏見があるかもしれません

おかげで、人々の背景を知るのは難しいことがあります。 あなたが科学プロジェクトに精通しているなら、それは私の懸念を大いに軽減します。

私たちにできることは、準備が整ったインクリメンタル修正だけで「pip 9.1」をリリースし、パイプラインにある3つのビッグチケット機能（の少なくとも1つ）の実装用にバージョン番号「pip10」を予約することです。

私は本当にこれが好きです。 ピップ10.0.0ではなくピップ9.1.0に+1

2018年の第1四半期にpip10のリリースを約束したいと思います[1]。アプローチとしてはそれで大丈夫です。

私は非常に興味深い脳波を持っていました-ピップは2018年10月12日に10歳になります。それはピップ10.0.0リリースを行うのに最適な日付です。 それは完全に異なるタイムラインです。 それまでシロイルカの機能を遅らせるべきだと言っているわけではありませんが、私の一部は、このバージョン番号と年齢も一致させたいと思っています。

PEP518が再び勢いを失う可能性が高いと思います。

私はそれがしないことを確認するために私ができることをします。 うまくいけば、@ xoviatも喜んでそうします。 :)

私たちが現在マスターで持っている部分的なサポートを取り消すのに何が関係するのか、誰かが感じていますか？

明日はこれを見ても構わない。 @dstufftは＃4144でレビューされたものだったので、これに関する彼の意見は価値があると思います。

注- @ dstufftと@xavfernandezの同意なしに、物事を取り消すほど大胆なことはしたくないので、彼らの発言も見てみましょう。

@dstufftには1日の時間が足りません。 彼はまた、倉庫がダウンしないことを確認する必要があります。

彼らが何を言わなければならないかも見てみましょう。

はい、お願いします。 :)

UXの観点から：「信頼の信頼」攻撃に包括的に対抗することは本当に苦痛です[1]、そして「私はすべてをソースからコンパイルする」と言う多くの人々が実際にはそうしていないことに気付くでしょう-彼らのプロセスのどこかで他の誰か（ランタイム環境やオペレーティングシステムプロバイダーからのツールチェーンのビルドなど）、または前世代の独自のプラットフォーム（Fedoraの新しいバージョンのビルドルートなど）から提供されたバイナリを信頼するブートストラップステップになります。 RHELは以前のバージョンのFedoraおよびRHELからシードされますが、完全にゼロから開始するわけではありません）。 GentooのようなソースベースのLinuxディストリビューションでさえ、Linuxカーネル、Cコンパイラ、ハードウェアドライバなどを備えた実用的なビルド環境を提供するインストーラーから始まります。

したがって、pip 10が、 --no-binary :all:は実行時の依存関係にのみ適用され、依存関係の構築には適用されないと言うのは完全に合理的だと思います。 人々がソースからビルドルートを明示的に構築したい場合でも、それは可能です-ビルド依存関係の暗黙的なソースビルドの許可に伴う固有の再帰的なブートストラップ問題のために、pip10が暗黙的に自動化しないだけです。

ただし、ビルド環境が完全に事前構成されていることを期待していることを示すために、ソースビルドの一部として暗黙的なバイナリブートストラップが必要な場合は、インストールを完全に失敗させる別の--no-implicit-builddepsオプションを追加するのが合理的です。 。 そうすれば、すべてがソースからビルドされていることを確認しようとしている人（ビルドの依存関係を含む）は、次と同等のことを実行できます。

pip install --no-binary :all: --no-implicit-builddeps -r build-requirements.txt
pip install --no-binary :all: --no-implicit-builddeps -r requirements.txt

そして、最初のグループがCPythonとPython以外のビルドツールチェーン以外のものをプレインストールする必要がなくなるまで、必要な数の個別のインストールグループを定義します。

その概念を将来補完する可能性があるのは、分離された環境で各ビルドを実行するのではなく、 --buildenv <path>と言って、必要なソースビルドに使用する事前構成済みのビルド環境を指定できるようにすることです。 ただし、それをpip10に取り入れようとはしません。10.xを「バイナリビルドの依存関係が許可されている」というハッピーパスと「バイナリビルドの依存関係が必要な場合はビルドに失敗する」という代替オプションに制限することをお勧めします。現在実行中のインタプリタではまだ利用できません。」

[1] https://www.schneier.com/blog/archives/2006/01/countering_trus.html

私は別のオプションを考えました。これは合理的で、あまりリファクタリングを必要としないでしょう。基本的に、ビルド環境のセットアップ中にメインスレッドを保留にするためにマルチスレッドを使用します。 アイデアは次のようなものですinstall.pyには、 BuildEnvironmentManagerがあります。

class BuildEnvironmentManager(Thread):
    '''Has references to literally everything (cache, resolver, etc.)'''
    def run(self):
        while True:
            requirement_list, future = self.build_environment_queue.get()

            # install the requirements using all of the things
            # that we have

            # then put the build environment in the future
            future.put(BuildEnvironment())

次に、別のファイルが作成されます（backend.pyは十分にいっぱいではなく、おそらくより多くのものを使用できる可能性があり、ツリーの下端にあるため、backend.pyを使用します）：

class Future(Queue):
    pass

class BuildEnvironmentQueue(object):
    def __init__(self):
        self._queue = Queue()

    def request_build_environment(self, requirement_list):
        f = Future()
        self._queue.put((requirement_list, f))
        return f.get()

    def get():
        return self._queue.get()

そしてoperations / prepare.pyで：

# This call will put the thread to sleep until we have a build environment
# with the requirements installed
self.build_environment_queue.request_build_environment(requirement_list)

これには、最小限のリファクタリングが必要であり、シリアル化されたBuildEnvironmentManagerがあり（ビルド環境を最適化でき、単一のオブジェクトで行われた要求を正確に把握できる）、すべてを1つのプロセスに含めることができるという利点があります（したがって、最悪のシナリオはデッドロックです）。 もちろん、他のスレッドではロギングを無効にする必要がありますが、それはそれほど問題ではありません。

queue.Queueベースのアプローチに関する私自身の質問に答える：それを使用するにはPython 2.7でhttps://pypi.org/project/futures/をベンダー化する必要があるため、concurrent.futuresに依存することは避けるのが最善です。

pipコードベースをよく知らなくても、ビルド環境管理を1か所に統合​​するという概念は魅力的なオプションのように思われます。

そのアプローチにはconcurrent.futuresは必要ありません。 Futureは、より説明的なラッパーです。

必要なプリミティブはキューのみです： https ：//docs.python.org/2/library/queue.html

これらの行をBuildEnvironmentManagerに移動できると思います。

私は多くの科学プロジェクトに携わってきたので、偏見があるかもしれません。 しかし、ホイールビルドの依存関係を持つプロジェクトのリストをガラガラと鳴らすことはできますし、ソースの依存関係を持つ1つのプロジェクトを本当に考えることはできません。 たぶん私は間違っています。

ええと、[Windows、macOS、Linux]以外のすべてのOSがあり、IIRCはmanylinux1でカバーされていません。

@rgommers PEP 518は、次のピップにある場合にホイールとして利用可能なビルド依存関係のみをサポートしても大丈夫ですか？

私の電話ではありませんが、ここで一歩前進できれば幸いです。 とにかくPEP518のサポートはオプションであるため、pip 10でホイールが使用可能な場合（私が言うケースの90％以上をカバー）にのみ機能することは、依然として大幅な改善です。

PyPIでホイールを許可しないプラットフォームでも、ローカルホイールキャッシュが残っていることに注意してください。つまり、pipが暗黙的にブートストラップできない場合でも、それらを印刷して「これらのビルド依存関係を何らかの方法でインストールする」と言うことができる場合があります。 、そしてこれはうまくいくでしょう」。

しかし、私たちが現在マスターで持っている部分的なサポートを取り消すのに何が関係するのか、誰かが感じていますか？

私はこれを調べました。 それほど難しいことではないようです。 私たちがこのように行くことに決めたら、私はそれのためにPRをすることを嬉しく思います。

ピップ10.0.0ではなくピップ9.1.0に+1

私はついにdistutils-sigスレッドを正しく読み、関連するPRとディスカッション（＃4351、＃4144、＃4799など）を見る時間ができました。 ピップ10を発表してからだと思います。 これは、部分的なPEP518サポート（9.1.0ではない）を使用して行う必要があることです。

このバージョン番号と年齢は一致するもの

残念。 :(

@ncoghlan多分このコメントはレーダーの下に滑り込んだ-https ： //github.com/pypa/pip/pull/4799#issuecomment -338416543

そうでない場合は、なぜそれが機能しないのかを説明していただければ幸いです。私はその種のセットアップをある程度理解しており、それについてもっと学ぶことに間違いなくオープンです。 :)

@pradyunsgこれはビルドキャッシュのアイデアの特定の実装であるため、ほとんど機能すると思います。 それがカバーしていない1つの側面は、「すでにビルドしようとしているものをビルドするように求められた」ことを検出する方法がないため、依存関係ループをビルドすることです。

pipは依存関係ループを魔法のように解決する必要はないことに注意してください。実際に無限ループに入るのではなく、依存関係ループを検出して、見つけたらすぐに失敗する必要があります。

依存関係のループを構築することはカバーしていません、

これは、バイナリのみのビルド依存関係では発生しませんか？

@pradyunsgリンクされたコメントは、ビルド依存関係のソースビルドを許可する方法に関するものでした。つまり、循環依存関係が潜在的な懸念事項になるということです。 バイナリ依存関係が必要な場合、 pipは当面は既存のホイールキャッシュに依存できます。

そうだね。 ありがとう！ :)

部分的なPEP518の実装がバイナリビルドの依存関係のみに制限されている（またはすでにpipホイールキャッシュで利用可能である）pip 10を支持しているのは、それがすべて含まれている場合です。

スレッド全体をまだ読んでいませんが、バイナリビルドの依存関係に制限することの1つの副作用は、多くの場合、ビルドの依存関係にCの依存関係を持たせることが不可能になることです。 はい、Windows、macOS、および一部のLinuxバージョンにはバイナリホイールがありますが、次のものはありません。

• glibcを使用しないLinux（Docker内のAlpine Linuxが人気があります）。
• FreeBSDなどのLinux以外の* nixオペレーティングシステム。

これは、たとえばCFFIベースのプロジェクトでは、PEP 518を使用できないか、それらのプラットフォームでアンインストールできることを意味します。

これはすでに提起されているかもしれません！ このスレッドは後で読みます。

@dstufftその通りです。 しかし、私たちが提案しているのは、pipキャッシュの使用はオプションであるということです。 したがって、最初にビルドの依存関係をpip wheelまたはpip installするだけで、それらはキャッシュに保存されます。

これはすでに提起されているかもしれません！

いいえ。 :)

これは、たとえばCFFIベースのプロジェクトでは、PEP 518を使用できないか、それらのプラットフォームでアンインストールできることを意味します。

それはそう。 :-(

私の頭の中でこれを回避する方法は、PEP 518の動作をオプトインにすることです- pyproject.tomlファイルがある場合は、分離+ビルド環境を使用します。それ以外の場合は、 setup.pyを使用する現在の動作にフォールバックします。

このスレッドは後で読みます。

してください。 :)

ドナルドとまったく同じコメントがありました。 このスレッドについての私の理解は、pip 10に実装する時間がないため、バイナリのみは一時的なものであるということです。正しいですか？

代わりに恒久的な決定として提案された場合は、もちろん-1です。

ドナルドとまったく同じコメントがありました。 このスレッドについての私の理解は、pip 10に実装する時間がないため、バイナリのみは一時的なものであるということです。正しいですか？

そのとおりです。 pipはソースの依存関係をサポートする必要がありますが、人員が不足しています。

私の頭の中でこれを回避する方法は、PEP 518の動作をオプトインにすることです。pyproject.tomlファイルがある場合は、分離+ビルド環境を使用します。それ以外の場合は、setup.pyを使用する現在の動作にフォールバックします。

私はこのコメントを読み直しました、そして私はここで反対するつもりです。 PEP 518のサポートはオプションではありません（PEP 517に関連する実装上の理由から）IMHOですが、これらのプラットフォームでプロジェクトをアンインストール可能にしないでください。

より具体的には、インストールする特定のプロジェクトは、PEP 518を取得するかどうかを決定するべきではありません。それは、ビルドの依存関係がホイールとして使用可能かキャッシュ内で使用可能かによって決定されます。 さらに、次のようなメッセージを吐き出すだけで、これらのプラットフォームでもPEP518サポートを必須にすることができます。

Error: build dependency X is not in the pip cache. Run "pip install X" before installing Y.

私自身の視点を要約すると：

1. 「ビルド依存関係の暗黙的なビルドサポートなし」は、機能の最初にリリースされたイテレーションで特定のクラスの問題（ビルド依存関係ループなど）が発生しないようにするためのpip10の一時的な制限と見なしています。 プラグ可能なビルドバックエンドサポートの将来の反復では、ビルドの依存関係の暗黙的なソースビルドを許可すると同時に、許可すると発生する新しい問題を回避するための適切な対策を講じることができます。
2. ビルドを実際に暗黙的に実行せずにエラーメッセージで関連するpython -m pip wheel X Y Zコマンドを出力することは、pipが誤ってマシンをフォーク爆弾することがないようにするため、現時点では適切な回避策です。
3. ビルドされる特定のホイールにpyproject.tomlファイルが含まれていない限り、またはコマンドラインから分離ビルドが明示的に要求されていない限り、分離ビルドはおそらくまだデフォルトではありません。 既存のプロジェクトは分離されていない動作を期待するため、これは下位互換性の問題です。 分離されたビルドがリリースまたは2つで利用可能になり、それらのユーザビリティの問題が解決されると、それらは一般的にデフォルトになる可能性があります（おそらく、分離されたビルドを暗黙的に生成するのではなく、使用する特定のビルド環境を指定するコマンドラインオプションを使用します）もの）

@ncoghlan念のために言っておきますが、デフォルトのビルド分離がないということは、PEP 517がないことを意味します（少なくとも私のアプローチでは）。これは、setuptoolsの最新バージョンのみがサポートしているためです（ユーザーのバージョンに関係なく、新しいsetuptoolsをインストールする必要があります）。コンピューター）。 実際には、PEP 517の実装に必要な労力が劇的に増加するため（PEP517および非PEP517コードが必要）、PEP517が少なくとも1年遅れる可能性があると思います。

既存のプロジェクトは分離されていない動作を期待するため、これは下位互換性の問題です。

ほとんどの人は、 pip install Xを実行してpip install Yを実行するCIスクリプトを持っています。 これらのプロジェクトでは、 pypproject.tomlを追加する必要があります。 ただし、 pyproject.tomlを追加するのはそれほど手間がかからないため、必要に応じてコマンドラインフラグを追加してビルドの分離を無効にすることができます。

プロジェクトのpip10にpyproject.tomlがない場合は、少なくとも警告を発する必要があります（PEP 517はサポートされないようです）。

@xoviat 「調整するのにそれほど多くの作業は必要ありません」は、下位互換性がどのように機能するかではありません。 もしそうなら、pipは今ではデフォルトの非venvインストールモデルとして--userに切り替えていたでしょう:)

PEP 517に関する限り、 pyproject.tomlファイルを追加せずにパッケージパブリッシャーとしてPEP 517に依存することはできないため、 setup.pyのみのプロジェクトがPEP517サポートを取得しない場合は問題ありません。デフォルトでは。

警告を吐いても大丈夫ですか？

プロジェクト自体もその依存関係も変更されていなくても、pipがアップグレードされたという理由だけで、現在正常に動作しているビルドが警告を発し始めた場合、問題と見なされます。

PEP 518および517は、関係するすべてのパブリッシャーが引き続きsetuptoolsのみに依存している既存のプロジェクトの中断をゼロにするように意図的に設計されました。

pipが、setuptoolsベースのプロジェクトであっても単一のPEP 518ビルドパスに統合することを目指すのは理にかなっていますが、そのための時間は、分離されたビルドがリリースまたは2つの価値のある実用的なものを見た後です。それらをまったくサポートする最初のバージョンで。

ドナルドとまったく同じコメントがありました。 このスレッドについての私の理解は、pip 10に実装する時間がないため、バイナリのみは一時的なものであるということです。正しいですか？

うん。 その通り。

セットアップツールベースのプロジェクトであっても、pipが単一のPEP 518ビルドパスに統合することを目指すのは理にかなっていますが、そのための時間は、最初のバージョンではなく、分離されたビルドがリリースまたは2つの価値のある実用化を確認した後です。それらをすべてサポートします。

+1

2つのメジャーリリースのように、古いパスを削除することを目指すべきだと思います。 ピップが完全に着地したとき、適切なPEP518サポート。 古いビルドロジックを非推奨にし、標準の非推奨ポリシーに従って削除する必要があります。

ニックの要約に同意します...

それはそれを実装するために必要な労力の量を劇的に増加させるからです

いいえ。この方法でPEP518を実装することには、大きな障害はないと思います。 これをpip内に実装する方法について、 https： //github.com/pypa/pip/pull/4799#issuecomment-339219397に短いコメントをしました。

私たちがやりたいのは、古いものから新しいものへのクリーンな移行を人々に提供することです。 したがって、現在のpip 9インストールロジックを変更しないでおく必要があります。これにより、基本的に、現在行っているすべてのことを正確な方法でサポートできます。

アーカイブにpyproject.tomlファイルを入れるということは、パッケージが新しい標準にオプトインしていて、新しい動作のサポートをテストする用意があることを意味します-分離とバイナリのみのビルドでビルド環境を通過します-依存関係（今のところ）。

いいえ。この方法でPEP518を実装することには、大きな障害はないと思います。

ここでPEP517について説明します。 混乱させて申し訳ありません。

両方のコードパスをチェックするには、テストを2回実行する必要があります。 ああ、PEP517はおそらく延期されています。

IMO、

1. プロジェクトにpyproject.tomlがない場合の警告は、非常に悪い考えのように聞こえます。 結局のところ、PyPIのプロジェクトの99％には現在pyproject.tomlがなく、エンドユーザーに何もできないという警告をスパムすることはできません（プロジェクトに問題を報告する以外は） ）何かが足りませんか？
2. ビルドの分離がPEP518でまったく言及されていなかったと思います。これは、pipがしばらくの間含めたかった追加機能ですが、同じPRが実装されたという偶然の事実を除いて、PEP518のサポートとは関係ありません。両方（AFAIR）。 したがって、ビルドの分離がここで問題を引き起こしている場合は、最初にPEP 518だけを使用し、フェーズ2として分離を追加しても問題ありません。ただし、その決定は実装者に任せます。

私は何かが足りないのですか？

いいえ。

最初はPEP518だけで、フェーズ2として分離を追加しても問題ありません。

PEP 518を実行して、分離を一緒にビルドする必要があると思います。これは、人々に分離ビルドに切り替えるための優れた方法だからです。

PEP518もPEP517も分離ビルドを必要としませんが、PEP 517は、適切な理由からそれらを推奨しています： https ：//www.python.org/dev/peps/pep-0517/#recommendations -for-build-frontends-non-normative

ローカルのバイナリアーティファクトキャッシュがないと、分離されたビルド環境は実用的ではありませんが、（ pipのように）それらの1つを取得すると、次の理由ではるかに実現可能になります。

1. ほとんどのインストールでは、最初にソースビルドを実行する必要はありません。
2. ソースビルドを実行する必要がある場合は、通常、キャッシュからビルド環境を設定します

同時に、分離されたビルド環境では、バグのあるメタデータがパブリッシャー自身のビルドを壊し、「ビルドの依存関係が完全に宣言されていません」と明示的に言う必要があるため、パブリッシャーの作業が少し必要になります。ビルドを行います。

したがって、 pyproject.tomlベースのビルドを最初から分離することで、自然な切り替えポイントが提供されます。これは、PEP全体が、実行時の依存関係とは別にビルドの依存関係を明確かつ一貫して宣言する方法を提供することを目的としているためです。 つまり、 setup.pyから切り替える人は、おそらくそのようなことを気にかけているためですが、新しいプロジェクトのために新しくやってくる人は、パッケージツールがジャンプすることを義務付けている別のフープとして扱います。終えた。

したがって、コードの記述に取り掛かる前に確認したいことがいくつかあります。

• PEP517のサポートはpip10のブロッカーではありません
• ピップ10のPEP518
  
  
  
  • pyproject.toml経由でオプトイン
  
  
  • バイナリのみのビルド依存関係のみをサポート
  
  
  • 分離されたビルド
  
  

PEP 517はまだ準備ができていないため、pip 10のブロッカーになることはできません。また、この時点で前方への明確なパスはありません（前方へのパスはありますが、明確ではありません）。

@xoviatのコメントに応えて、実装の課題を要約し、このスレッドをすばやく読んだ後、コメントと質問があります。

まず、爆発する可能性のあるものの再帰の問題に関しては、一般に、再帰関数はすべて反復関数に「変換」できます。 そのアプローチがより多くの制御を提供することによってここで役立つことができるかどうか疑問に思います。

次に、Python内からpip関数を呼び出すのとは対照的に、シェルアウトは何を購入しますか？ シェルアウトが達成しようとしていることをすべて実行する内部API関数を作成/リファクタリングできなかった理由はありますか？ これにより、（CLIパラメーターと比較して）呼び出しを呼び出す際の柔軟性が向上します。 これにより、プロセス全体の状態をより簡単に管理できるようになるため、より詳細な制御が可能になります。

シェルアウトが達成しようとしていることをすべて実行する内部API関数を作成/リファクタリングできなかった理由はありますか？

次に、Python内からpip関数を呼び出すのとは対照的に、シェルアウトは何を購入しますか？

それは私たちが現在持っていない時間を買います。 pipはすでにリリーススケジュールより遅れています。

まず、爆発する可能性のあるものの再帰の問題に関しては、一般に、再帰関数はすべて反復関数に「変換」できます。

私は反再帰ではありません。 私は反プロセス再帰です。 100％のCPU（Pythonでは20％）を使用する場合は問題ないと思いますが、最終的には、ユーザーがタスクマネージャーを開いて、そこにある最大15のプロセスを強制終了できる必要があります。 私にとって、プロセスの爆発を引き起こす可能性のある状況は受け入れられません。

しかし、それはなぜそれが時間を買うのかという質問には答えません。 同じことを行う内部API関数を作成するのが難しいのはなぜですか？

いずれにせよ、シェルアウトによって特定の問題が解決された場合、このアプローチを簡単にする1つの可能性は、必要な情報を簡単に渡すことができるプライベート/内部CLIコマンドを一時的に公開することです（たとえば、シリアル化されたPythonオブジェクトの場合もあります）。 、など）。

しかし、それはなぜそれが時間を買うのかという質問には答えません。 同じことを行う内部API関数を作成するのが難しいのはなぜですか？

簡単だと思うなら、先に進んでください。 私はそれを皮肉なことに言っているのではありません。すべての問題を解決するので、どうぞどうぞ。

簡単ではないと思います。 なぜそれが難しいのかについての洞察を得るために質問をしています。 （時間を節約できると言っていたので、これについて考えたことがあると思います。）

私が信じているpkg_resourcesのような場所にキャッシュがあるため、通常、サブプロセス内で個別のpipインストールを実行する必要があります（私はそこで間違っている可能性があります）。

これは、 pipを呼び出す必要があるという意味ではありませんが、CLIを介してデータをシリアル化するAPIを作成し、 python -c "from pip._internals import coolapithing; coolapithing(sys.stdin.read())"を呼び出して、stdoutからさらにデータを読み取ることができます。 このようなAPIを使用してスタックに変換することで、pipの呼び出しpips呼び出しpips呼び出しpipsの再帰ソリューションをスタックに変換することができます（すべての再帰はスタックとしても記述できるため）、基本的にはプライベートAPIを作成するだけです。それはプロセスとして呼び出されます。

私はまだこのスレッドを読むことを計画しています（最近たくさんのプレートが回転していました！）が、もう1つ、リリーススケジュールは実際にはありません。ターゲットの日付ではなく、準備ができたときにリリースします。 いつリリースしたいのかという一般的な考えを持っていることもありますが、それが決まっているわけではありません。

最終的には、Pythonには、物事が制御不能にならないようにするための最大の再帰深度があります。 そのアプローチを採用した場合は、それを実装する必要があります。

はい、スタックベースのアプローチにより、かなり深くなることが非常に効率的になります（たとえば、依存関係ループ以外の何よりもはるかに深くなります。たとえば、文字通りすべてのパッケージに依存し、それでも問題ないものを作成できます）。行うことは、ループを検出することです。

ループ検出を行うためのかなり素朴で簡単な方法の1つは、スタック上のアイテムの数に上限を設定し、この制限に達した場合は必ずループ状態になってエラーになる必要があると言うことです。 もちろん、その欠点は、ループができるだけ早く検出されないことと、ビルドの依存関係チェーンが深いパッケージでは、制限が機能しないことです。

一般的に優れたオプション（スタックベースのアプローチを使用するとスタック全体にアクセスできるため）は、単にスタックをトラバースして、インストールしようとしているアイテムがすでにスタックのどこかにあるかどうかを確認することです。ループが発生したためにエラーが発生しました（このエラーはエンドユーザーに表示されるか、最終的にリゾルバーにバブルアップして別のバージョンを試す可能性がありますが、速度は大幅に低下します）。

そして@cjerdonekの質問に直接答えるために：原則としてこれは難しいことではありませんが、物事をトリッキーにしているのは、 pipが現在機能する方法でのいくつかの埋め込まれたアーキテクチャの仮定であり、各ソースが構築される世界ではもはや真実ではありませんインストール環境で直接実行するのではなく、独自の分離されたビルド環境を取得します。

つまり、 pipの既存の依存関係管理ロジックを、これらの内部アーキテクチャの制限に遭遇することなく、また現在機能しているコードを壊すリスクを冒すことなく再利用する最も簡単な方法は、サブプロセスでpipの別のインスタンスを実行することです。 依存関係ループの検出とベイルアウトに失敗すると、ビルドを実行しているシステムにフォーク爆弾が投下される可能性があるという結果を除いて、これはほとんど問題ありません。

反復/スタックベースのアプローチに変換し、パターンpython -c "from pip._internals import coolapithing; coolapithing(sys.stdin.read())"を使用して内部pip関数にシェルアウトするという@dstufftのアイデアが好きです。 これは、議論に基づくと最も単純であり、堅牢であるように思われます。

これに向けた最初のステップは、単純な再帰的アプローチを、期待される入力と出力（少なくともスケッチ）を備えた単一の再帰的Python関数にまとめることであり、その後、これを反復アプローチに変換/変換できると思います。 そして、はい、ループを防ぐために訪問した呼び出しのsetを維持することができます。これは、解決するのが簡単な側面の1つのようです。

再帰的アプローチを反復的アプローチに変換することについて、もう少し調べて考えました。 @xoviatのPEP518（PR＃4799）に関する部分的な作業は、再帰のポイントを見つけるのに役立ちました（おそらくすでにご存知の方もいらっしゃると思います）。 それは彼のコードコメントにあります：

# TODO: Use single process with recursion handling

次に、 pip install ...を呼び出します。

私の考えでは、これはおそらく次のような変更を加えたpip install （ビルドの依存関係用）のバリアントによって解決できるように見えます。

• インストールにサブインストールが必要ない場合は、インストールを実行します。
• それ以外の場合は、必要なサブインストールの（おそらく部分的な）リストを返します（たとえば、stdoutへの書き込みがまだ機能しない場合は、合意されたファイルに情報を書き込むことによって）。

このようにして、トップレベルのルートプロセスは、ビルドの依存関係のツリーを段階的に生成できます。 また、見つかった葉を処理できます。 葉が処理されると、以前は葉ではなかったノードが葉になり、以下同様に続きます。 この実装では、どの時点でも、サブプロセスで発生するpip-installは最大で1つだけです。

上で提案したものとのわずかな違いは、必要なpipコマンド/サブプロセス呼び出しが、候補インストールに必要なサブインストール呼び出しのリストを返す/出力できることです（ pip get-subinstallsまたは単にpip subinstalls指図）。 上記で提案したこととの唯一の違いは、このコマンドが情報の報告に限定されることです。 実際にはインストールは行われません。 したがって、それを実装することは、テストがより簡単で簡単になる可能性があります。

@cjerdonekそのアイデアに問題はありません。 しかし、最終的には誰かがそれを実装する必要があり（ @pradyunsgは今週末に何かに取り組むつもりだったと思いますか？）、いつものように、さらに多くの困難が発見される可能性があります。

何かが起こった。 他の誰かがこれを手に入れたいのなら、私にはありません
問題。 :)

@dstufftのアイデアも好き

2017年10月29日、日曜日、08：47 xoviat、 notifications @ github.comは次のように書いています。

@cjerdonekhttps ：//github.com/cjerdonek問題はありません
その考え。 しかし、最終的に誰かがそれを実装する必要があります（私は思う
@pradyunsghttps ：//github.com/pradyunsgは何かに取り組むつもりでした
今週末？）そしていつものようにそれからもっと多くの困難が発見されるかもしれません。

—
あなたが言及されたので、あなたはこれを受け取っています。

このメールに直接返信し、GitHubで表示してください
https://github.com/pypa/pip/issues/4802#issuecomment-340234567 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/ADH7SYImpWgJGg-DzQRcO_9hHfE6ZxEAks5sw-5RgaJpZM4QBdSg
。

これに戻って、@ dstufftによって提案されたスタック+内部呼び出しアプローチを進めたいですか？

/ ping @ncoghlan @pfmoore @xavfernandez

はい、お願いします。 これを前進させるために何か。

ピップ10のリリースに関連してPEP517とPEP518の立場を要約できる人はいますか？ 具体的には：

1. マスターは現在リリース可能な状態ですか？ 最後に聞いたところによると、PEP 518のサポートが壊れていました（PEP 518に関連するリリースブロッカーの問題が少なくとも1つあります-＃4647）。
2. PEP517および/またはPEP518の実装が、利用可能になるまでpip 10を遅らせるのが合理的なタイムスケールで機能する可能性はありますか？
3. （1）で修正したとすると、PEP517 / 518なしでpip10リリースを実行しますか？ リリースについてのヘッドアップメールを作成したので、人々はそれが来ることを知っています。 そして、そこにはかなり重要な修正がいくつかあり（たとえば、Windowsのエンコーディング修正）、リリースすると便利です。

私はリリースブロッカーを待っていると感じていますが、それらのピップ10をブロックするためのPEP517 / 518サポートに十分に近づいていません。 しかし、PEP 518の実装の一部を除いて、＃4647に取り組んでいる人はいないと思います。

代替オプションの1つは、現在のPEP 518サポートの制限を文書化し、リリースブロッカーから＃4647をダウングレードすることです。 それが実行可能かどうかを知るためのユースケースについては十分にわかりません。

私はこの議論を見たばかりです-フォーク爆弾として機能しがちな中途半端な初期実装についてお詫びします。そしてそれを理解し、より良いアイデアを考え出すために時間を割いてくれた皆さんに感謝します。

FWIW、ビルド要件のためにホイールをインストールするように制限することは、最初のバージョンでは許容できる妥協案だと思います。

これはまた、フリットがそれ自体のビルド要件にならないように、おそらく問題を修正する必要があることを私に思い出させます。

フォーク爆弾として機能しがちな中途半端な初期実装についてお詫びします。

謝罪は必要ありません。 私が言ったように、あなたは最初の試みでこれらの問題を予測することはできません。 私たちが今知っていることを知っていても、PRを遅らせることは、これらの議論を延期したでしょう。

マスターは現在リリース可能な状態ですか？

IIUC、それは今のところシステムをフォーク爆撃することができます。 あれは正しいですか？ もしそうなら、そうではないと思います。

PEP517および/またはPEP518の実装が、利用可能になるまでpip 10を遅らせるのが合理的なタイムスケールで機能する可能性はありますか？

簡単な（短期的な）解決策は、ビルドの依存関係をホイールに制限することだと思います。 来週のいつかそれを突き刺そうとします。 それが実現しない場合は、現在のPEP 518サポートをマスターから削除し、そこから10.0.0を削除すれば問題ありません。

PEP 518の実装の一部を除いて、＃4647に取り組んでいる人はいないと思います。

つまり、ソースビルドの依存関係を許可したPEP 518の完全な実装ですか？

ああ、そして＃4647について-上記の@xoviatの説明によると、コードの変更/移動とオブジェクト（具体的にBuildEnvironment ）の所有権/可視性が必要になる修正は簡単ではありません。

ホイールに制限するのは、この行を変更するのと同じくらい簡単なはずだと思います。

https://github.com/pypa/pip/blob/fc6b2c192088737f81259b6446f627f20ce46443/src/pip/_internal/wheel.py#L696

に：

finder.format_control = FormatControl(set(), set([':all:']))

2番目のフィールドには、バイナリとしてのみ検索するパッケージのセットがあります。 ':all:'の特殊なケースは、すべてのパッケージを意味します。

はい。 しかし、それだけでは＃4647に対応できません。 また、このコードはどれも行きません
リゾルバを介して。

2017年12月2日土曜日01:23に[email protected]は次のように書いています。

ホイールに限定するのは、これを変更するのと同じくらい簡単なはずだと思います
ライン：

https://github.com/pypa/pip/blob/fc6b2c192088737f81259b6446f627f20ce46443/src/pip/_internal/wheel.py#L696

に：

finder.format_control = FormatControl（set（）、set（['：all：']））

2番目のフィールドには、バイナリとしてのみ検索するパッケージのセットがあります。
'：all：'の特殊なケースは、すべてのパッケージを意味します。

—
あなたが言及されたので、あなたはこれを受け取っています。

このメールに直接返信し、GitHubで表示してください
https://github.com/pypa/pip/issues/4802#issuecomment-348598368 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/ADH7SUi0QMS3rr5Iba90XWZmFweGmqeBks5s8FlEgaJpZM4QBdSg
。

そうです、他にもたくさんの問題があります。 しかし、それはそれがフォーク爆撃を防ぐはずです、それは私が最も差し迫った懸念であると思います。

誰かが私の元のPRを引き継ぐことを望む場合（「PEP518の問題を修正する」）、
ビルドの分離が行われないように変更するのは難しいことではありません
pyproject.tomlなしで有効になります。 マージされなかった元の理由
ソースから依存関係をインストールするためのサポートを削除したことでした
PEP518。しかし、今では人々はPEP518が
ピップ10にまったく入っていないので、彼らはそのPRを受け入れるのにより適しているかもしれません。 私
個人的にそれを擁護する時間はありませんが、それは他の人を止めるべきではありません
ほんの数行の変更が必要になるので、それを前進させることから
（PEP 518テストのxfailingは別として）。

実際、私のより良い判断に反して、pip開発者が私の条件に同意する場合は、すぐにPEP517と518の両方を実装するつもりです。

1. 依存関係は最初はホイールからのみになります
2. pipには、最終的には削除されますが、最初は内部ビルドバックエンドがあります

1に問題はありません。 私はどちらの方法でも2を好みません。

2017年12月3日02:36に、 xoviatnotifications @ github.comは次のように書いています。

実際、私のより良い判断に反して、私は両方のPEPを実装する用意があります
ピップ開発者が私の条件に同意する場合は、まもなく517と518：

1. 依存関係は最初はホイールからのみになります
2. pipには、最初は内部ビルドバックエンドがありますが、
   最終的に削除されます

—
あなたが言及されたので、あなたはこれを受け取っています。

このメールに直接返信し、GitHubで表示してください
https://github.com/pypa/pip/issues/4802#issuecomment-348720096 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/ADH7ST6riptZkYMap5Z5SstRf-VmE7eAks5s8bu5gaJpZM4QBdSg
。

参考までに、条件は任意ではありませんが、最初の実装を可能にするためにあります。 @pfmooreはこれで大丈夫ですか？

私は、「私のより良い判断に反して...私の条件に同意する」という申し出の口調に特に満足していません。 他のpip開発者がこの提案を喜んで受け入れても、私は異議を唱えるつもりはありませんが、個人的には、実装の詳細に関する議論全体を再開する時間はありません。 基本的に、これについては@dstufftと@xavfernandezに任せます（ @pradyunsgはすでに彼の見解を示しています）。

提案のトーンは、最初の実装がどのようになるかについての根本的な不一致のために実装の方法が閉鎖されたためです。 別の実装の議論に移るよりも、今は原則に同意したいと思います。

私も音色にあまり満足していないとだけ言います、それは
ただ、なぜそのトーンが使われたのかを説明する時間もエネルギーもありません
など。私の終わりからの簡潔な返信の同じ理由。

たぶんまた述べる価値があります、私はバイナリのみのビルド依存関係でクールです
長期的ではなく、最初の実装。 これは適用されません
実行時の依存関係（それは別の場所でも何らかの形で発生しているため）
討論）。

2017年12月3日、日曜日、23：37 xoviat、 notifications @ github.comは次のように書いています。

オファーのトーンは、
何についての根本的な意見の不一致により、実装は閉鎖されました
最初の実装は次のようになります。 私はむしろ同意したい
原則は今では別の実装の議論に移ります。

—
あなたが言及されたので、あなたはこれを受け取っています。

このメールに直接返信し、GitHubで表示してください
https://github.com/pypa/pip/issues/4802#issuecomment-348802032 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/ADH7ScUh-BveonoTxZ5FkkeSynFvoLb8ks5s8uNRgaJpZM4QBdSg
。

正直なところ、これらの機能をpip 10に含めることとは関係がないため、投稿のトーンについてさらに議論するのは、おそらく誰かの時間を有効に活用することではありません。ただし、私の条件がどちらの@pfmooreからもマージできることを保証する必要があります（誰もそのような保証をすることができないことを示しました。これは、ここでの時間に対して誰も支払われないことを考えると許容できます）、 @ dstufft 、または@xavfernandez。

繰り返しますが、条件は私の個人的な意見ではありませんが、実装主導型です。 これらの条件を緩和すると、実装を約束できないので、PRの準備に時間を費やして、差分を読んで「ああ、なぜこの行がここにあるのか」と尋ねる人は意味がありません。 そして「ああ、これはマージできないのですか？」 PRの目的が正確に何であるかについて誤解があったからです。

トーンに同意しました。 私のポイントは、変更をマージしないということです[1]。したがって、ここでは私の見解はそれほど重要ではありません。

[1]明らかに、実装を見たことがないので、私の理由がコードの品質に関する懸念とは関係がないことは明らかだと思います。それは、コードを十分に理解するための時間がないことです。基本的に、マージすることをいとわない。

@xoviat上記で説明した反復的アプローチと再帰的アプローチに関する実装計画は何ですか？

また、明確にするために、最初にマージ可能なPEP 517および518の部分的な実装を完了し、次にマージ可能な完全な実装を完了すると言っていますか？ それとも、部分的な実装のみを行うと言っているのですか、それとも、必ずしもマージ可能ではない初期の段階を経て完全な実装を行うと言っているのですか？ （私は部分的に、あなたのコメントで「最初に」そして「最終的に」あなたが何を意味するのかをよりよく理解しようとしています。）

最初の条件は、再帰の問題全体を排除します。

また、明確にするために、最初にマージ可能なPEP 517および518の部分的な実装を完了し、次にマージ可能な完全な実装を完了すると言っていますか？

私が言っているのは、部分的な実装を完了することです。これは、ユースケースの95％で機能します。 特に、依存関係に車輪があり（現在非常に一般的）、manylinux / windows / OSXプラットフォーム（大多数のユーザー）を使用している場合。

完全な実装ではありません。 しかし、マージ不可能なPRを取得する方法は、標準に準拠するかどうかにかかわらず、「オールオアナッシング」アプローチを実行しようとすることです。

完全な実装では、それぞれが個別のPRを必要とするかなり厄介な問題をソートする必要があることに注意してください（100以上のコメントを含むPRがあると、通常、コードが十分にレビューされていないことを意味します）。 [1]

[1] https://github.com/btc1/bitcoin/pull/11#issuecomment -313843216

この問題を今すぐクローズします-ビルドの依存関係としてホイールのみをサポートするpip10のPEP518の予備サポートがあります。 完全なサポートについて議論するための新しい問題と、PEP 517サポートについての別の問題を開きます（関連するものとしてここから引用します）。

@ncoghlan @rgommers @cjerdonekに洞察を与えてくれて、ここで助けてくれてありがとう。 PEP518の最初の実装をしてくれた@takluyverに感謝します。これらの変更の実装に協力してくれた@ghost ）に感謝します。 現在のサポートの改善にご協力いただき、ありがとうございます。

PS：100番目のコメント！ ：tada：

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