これをバックエンドの観点から見ると、「ツリー外のビルド」という考えは実際には無意味です。 バックエンドには、プロセスの現在のディレクトリの形式で「ソースツリー」が与えられ、ビルドを実行するように求められます。 そのディレクトリがsdistから抽出されたのか、VCSからチェックアウトされたのか、他の場所からコピーされたのかを知る方法はありません。 実行できるのはビルドだけです。ビルドに必要なものがない場合は、失敗を報告してください。

そのため、考えられる解決策はほとんどありません（3）IMO-バックエンドにはインプレースビルドとは何かという概念がないため、そのようなビルドが安全かどうかはわかりません¹ 。

（2）に関しては、私は一般的にこのような追加のオプションに反対しています。 最善の方法がわかっている場合はそれを行う必要があります。そうでない場合は、問題をユーザーに渡すことは特にフレンドリーなオプションではありません。 ここでの問題は非常に微妙なので、正しい選択が何であるかを知っているユーザーはほとんどいないと思います。そのため、2つのオプションを試し、盲目的に「機能するものは何でも」を使用しているユーザーがいる可能性があります。 また、サポートへの影響は重要です。オプションを提供することは、ビルド結果が少なくともいくつかのケースで異なることを期待していることを明確に意味します。それでは、違いが期待どおりであることをどのようにテストしますか？ インプレースビルドフラグが必要になるかどうかについてユーザーを教育する責任がありますか（ドキュメントを介して、またはどちらを使用するかわからないユーザーによって提起された問題の結果として）？

そうは言っても、私はピップを単に適切な場所に構築することに反対していません。 私たちがそうしない理由は、前のビルドから残ったアーティファクトが次のビルドで使用されたが、異なるオプションでビルドされた場合があるためだと思います（たとえば、デバッグモードでビルドされたオブジェクトファイルがリリースビルドにリンクされている同じツリーから実行されます）。 ただし、バックエンドはこのような問題が発生しないようにする必要があると言うのは合理的です。発生した場合、それはバックエンドのバグであり、それを防御しようとするのはピップではありません。 ただし、そのようなスタンスをとることが特にユーザーフレンドリーであるかどうかはわかりません。これは、インクリメンタルビルドのトピックに関するPEP 517の議論中に出てきたものであり、当時は延期されるほど物議を醸していました。

私の好みは、長い間、sdistを作成し、それからホイールを作成することでした（オプション1）。 ピップの構築は問題ありませんが（上記のように、バックエンドからの通知は期待できないため、安全であることに同意できる場合）、コミュニティが必要になると思います。より広い意味（バックエンド、pip /フロントエンド、エンドユーザー）を打ち砕くための議論。

¹もちろん、PEP 517を更新して、「アウトオブツリー」ビルドではなく「インプレース」ソースツリーを構成するものを

ソリューション4.（pipを常にインプレースでビルドするように変更）および5.（pipをデフォルトでインプレースでビルドするように変更し、ツリー外でビルドするオプションを追加）を追加しました。

次の理由で、sdist（ソリューション1）を介した構築に関する感情が混ざり合っています。

1. 一部のプロジェクトでは、sdistからwheelへのパスが壊れている可能性があります。 sdistsからのビルドが機能することを検証することの価値はわかりますが、デフォルトで実行すると、多くのエンドユーザービルドが確実に壊れます。
2. 大規模なsdistを使用するプロジェクトや、追加のサブプロセス呼び出しにより、パフォーマンスに影響があります。
3. プロジェクトがビルドされたアーティファクトを公開し、ソースリリースのお気に入りのコードホスティングプラットフォームを参照することは非常に一般的であるため、個人的にはsdistsにあまり重点を置くべきではないと思います（たとえば、VCSチェックアウトの存在に依存するバックエンド建物は、動作するsdistを生成するためにフープをジャンプする必要があります）。 また、PEP 517では、バックエンドがUnsupportedOperationに対してbuild_sdist UnsupportedOperationを調達できるようになっています。

ディスカッションに関するこの

私は、解決策3の道筋が明白とはほど遠いことに同意します。

また、可能であれば、追加のオプションを避けるべきであることに同意します。

また、リンクされたディスカッションスレッドでインプレースビルドを支持する声がいくつかあったことにも注意しますが、そのアプローチを検討する場合は、その特定の主題に焦点を当てたコミュニティディスカッションが必要です。

• sdistを所定の位置に構築し、一時的な場所でsdistを開梱して、そこから構築します。

これは良いアプローチだと思います。

IMOの可能性は、これはローカルディレクトリを含むほとんどのpip install実行で単一のパッケージに対して実行されることです-最も一般的にはpip install .を想像します。 これは、パッケージ開発ワークフローの一部として行われる可能性があります。

この動作は次のようになります。

• バックエンドがsdistを作成できない場合は、local-dir-> Wheel（インプレース）を実行します
  
  
  
  • この場合、local-dir-> Wheelがべき等操作であることを確認する責任は、バックエンドにあると思います。
  
  
• バックエンドがsdistを作成できる場合は、local-dir-> sdist-> unpacked-sdist-> wheelを実行します。

local-dir-> sdist-> Wheelを実行すると、追加の呼び出しセットがあります。 ただし、特に開発中に、生成されたsdistが正常であることを検証することは合理的だと思います。 toxはすでにワークフローの一部としてこれを行っています。ここで、setuptoolsのあまり使いにくいインターフェースをカバーするマニフェストを確認してください。

全体として、ローカルディレクトリを指定した場合のsdistの構築コストは、プロジェクトでのこのようなエラーを防ぐのに十分な価値があると思います。特に、ローカルディレクトリからインストールする人は、プロジェクト自体の開発者である可能性が高いためです。

展開に関しては、＃6536がどのように発生するかを待ちたいと思います。 転送できるいくつかのことを確実に学びます。

sdistを構築して解凍し、インストールするよりも、sdistを使用せずにインプレースでビルド/インストールする（つまり、 setup.py installまたはsetup.py bdist_wheelまたはPEP 517バックエンドでbuild_wheelを呼び出す）方が好きです。それから。 私の具体的な理由は次のとおりです。

1. 箱から出して最大数のユーザーをサポートします。
   
   
   
   1. pipがlocal-dir->インストールされていると仮定します（ホイールビルドインプレースまたはsetup.py install介して）。 local-dir-> installedから移動したいユーザーはpip install local-dir実行できます。 local-dir-> sdist-> installから移動したいユーザーは、自由にsdistを作成してから、 pip install ./path/to/sdist実行できます。 sdistを構築できる代替ツールはたくさんあります。これは、PyPIにアップロードするディストリビューションを手作りしない限り、ユーザーがすでに持っている可能性が高いものです。
   
   
   2. ここで、pipがlocal-dir-> sdist-> installedを実行すると仮定します。 local-dir->インストール済みから移動したいユーザーには、pipを含むオプションはありません。 local-dir-> sdist-> installから移動したいユーザーは、 pip install local-dir実行できます。 オプションのないユーザーは、動作を制御するためのオプションをpipに要求するか、他の方法では必要のない別のツールを見つける必要があります。
   
   
2. local-dir-> sdist-> installedを実装する場合、おそらく、VCSベースの要件に対しても実装しますか？ もしそうなら、それはより多くの仕事です。 そうでない場合、それはコードを介した追加のパスであり、インストールの処理方法における逸脱であり、ユーザーが覚えておく必要があるか、サポートを提供するときに覚えておく必要があります。
3. 実装する作業の量が最も少ない。 local-dirを実装するために変更する場所は3つあります->インストール済み（ここ、ここ、およびここ）。 local-dir-> sdist->インストール済みの場合、＃6607が完了するまで、これの実装に触れたくありません。そうしないと、アーティファクトのダウンロード/ハッシュチェックと同様に、コードベースの多くの場所で終了すると思います。
4. ローカルディレクトリ->インストールされたコードパスをカバーするには、IMOの既存のテストで十分なので、テストする作業量は最小限です。 local-dir-> sdist->インストール済みパスの場合、実際にsdistを構築していること、およびフォールバックがホイールを直接構築するために機能することを確認する必要があります。
5. 最小の作業量（計算上）。 他の場所で述べたように、local-dir-> sdist-> installedは追加のサブプロセス呼び出しです（そしてそのサブプロセスは作業を行っています）。 また、ホイールビルドを実行する前に、pipがsdist（helloウイルススキャナーやその他の低速ディスク）を解凍する必要があることも意味します。

アプローチに関係なく、インプレースで行うことで私が目にする唯一の問題は、setuptoolsビルド（これはレガシーおよびPEP 517に当てはまると思います）の場合、プロジェクトディレクトリに.egg-infoれ、誤ってしまうことです。そのディレクトリでpython -m pipしてpipが呼び出された場合、「インストール済みパッケージ」として。 これは＃4575で修正され、スキームのインストール済みパッケージのクエリに現在のディレクトリが含まれない可能性があります。

sdistビルドをスキップしてツリー内ビルドを直接実行するというアイデアは、デフォルトでpipが採用するより良いアプローチであり、local-dir-> sdist-> wheelを実行しようとしないことに同意するようになりました。

Fedoraでは、Python RPMパッケージをビルドするとき、私たちは恐竜であり、シンを実行する標準的な方法はpython setup.py buildを使用することです。 PEP 517では、代わりにpip wheelを使用する「暫定的な」方法を追加しました。 ただし、拡張モジュールでは、pipがそれらをビルドするために使用する「ソースをtmpに移動し、そこからビルドする」アプローチに問題があります。

私たちのビルド機構はいくつかのコンパイラフラグを挿入しているので、ビルドアーティファクト（この場合は.so拡張モジュール）にはソースに関するメタデータが含まれています。 後で、ビルドアーティファクトをトラバースし、この情報を抽出し、ソースを/usr/src/debugにコピーして、特別な*-debugsource RPMを介してインストールするシェルスクリプトがあります。 機械はすべてが作業ツリー内に構築されることを期待しており、外部に構築された場合は実際にはうまく機能しません。 これが私たちの側の問題を軽減するために（一緒に）できることです：

1. $TMPDIR環境変数を設定して、RPMスクリプトが予期する場所に配置します（つまり、 export TMPDIR=%{_builddir}/.tmp （および作成））
2. pip wheelを--no-cleanオプションとともに使用して、コピーされたソースを$TMPDIR
3. シェルカンフーを実行して、「ソースは何ですか」という情報を正しい場所に書き換えます： find %{buildroot} -iname '*.so' -print0 | xargs --no-run-if-empty -0 -n1 /usr/lib/rpm/debugedit -b "%{_builddir}/.tmp/pip-req-build-"* -d "$PWD"
4. （オプション： $TMPDIR手動でクリーンアップします。）

3番目のステップは、実装の詳細が多すぎるため、特に好きではありません。

• /usr/lib/rpm/debugedit APIと場所（および存在）
• pip-req-build名前
• pipがソースを構築するメカニズム

pipが常に適切に構築される場合、またはこのためのコマンドラインスイッチがある場合、問題は解消されます。

ダウンストリームレポート： https ：

sdistビルドをスキップしてツリー内ビルドを直接実行するというアイデアは、デフォルトでpipが採用するより良いアプローチであり、local-dir-> sdist-> wheelを実行しようとしないことに同意するようになりました。

また、インプレースホイールビルドを行うというアイデアを受け入れる傾向が強まっています。 私の残りの予約は次のとおりです。

1. バックエンドが「正しく」動作することに依存します。たとえば、以前のビルドの残りのデータに基づいて異なる結果が得られないなどです。 私はその仮定をすることは問題ありませんが、「pipが私のホイールを間違って構築した」と人々に言われ始め、それがバックエンドの問題であることがわかるだけでデバッグする必要がある場合、サポートコストが心配です。
2. どのようなアプローチをとる場合
3. 上記の結果として、現在の「コピーアンドビルド」アプローチに依存していることがわかっているプロジェクトがないことを確認する必要があります。この変更でプロジェクトを壊すかのように。

...そしてもちろん誰かがこの変更を実装するPRを書く必要があります（テスト、ドキュメントなど-通常のもので）そうでなければ私たちがしているのは話しているだけです🙂

バックエンドが「正しく」動作することに依存します。たとえば、以前のビルドの残りのデータに基づいて異なる結果が得られないなどです。 私はその仮定をすることは問題ありませんが、「pipが私のホイールを間違って構築した」と人々に言われ始め、それがバックエンドの問題であることがわかるだけでデバッグする必要がある場合、サポートコストが心配です。

「クリーンな」フックを含めるようにPEP517インターフェイスを拡張することは理にかなっていますか？ とにかく、他の試みを可能にするためのポイントとして、おそらくそれが必要です（たとえば、編集可能なインストールの実装、PEP 517プロ​​ジェクトをビルドするパッケージ開発ツールのビルド）。 pipはここでそれを呼び出して、ツリー内ビルドを実行する前にジャンクが残っていないことを確認できます。

「クリーンな」フックを含めるようにPEP517インターフェイスを拡張することは理にかなっていますか？

多分？ しかし、pipが自動的にclean呼び出す場合、インクリメンタルビルドなどを行うためにそうしないことを望んでいる人が必ずいます。 そして、私たちは別のオプションに行き着きます。

私の傾向は、「インプレースビルドが正しく機能することを保証するのはバックエンドの責任であると想定できる必要がある」という私の立場に固執することです。 それが受け入れられないことが判明したとしても、それが機能しない理由の具体的な例を入手することは、単に推測するのではなく、問題について何をすべきかをよりよく理解するのに役立ちます。

1. バックエンドが「正しく」動作することに依存します。たとえば、以前のビルドの残りのデータに基づいて異なる結果が得られないなどです。

これを明示的な要件にするために、PEP-517を拡張したいと思います。

これを明示的な要件にするために、PEP-517を拡張したいと思います。

それはすでにこれを言っています：

バックエンドは、中間アーティファクトをキャッシュの場所または一時ディレクトリに保存する場合があります。 キャッシュの有無によって、ビルドの最終結果に重大な違いが生じることはありません。

バックエンドが意図的にこの要件に違反する可能性はそれほど高くありません。ユーザーは自然に問題をpipの問題として報告し、バックエンドプロジェクトにリダイレクトされるため、少し余分なオーバーヘッドが発生します。

Fedoraの回避策を見つけようとすると、 https：//github.com/pypa/pip/issues/7872に見舞われました

＃7731とその仲間たちとの「.egg-infoin cwd」の問題を解決したので、それを適切に構築するときに心配することが1つ少なくなります。

そのため、オプション4（常にインプレースでビルド）が＃7882で実装されました。

現在（＃7951に従って）pipのベータリリースであるpip20.1b1を公開しています。 このリリースには、この問題の解決策を実装した＃7882が含まれています。

この号の参加者がベータ版をテストし、新しいバグをチェックすることで私たちを助けてくれることを願っています。 火曜日のメイン20.1リリースの前に、潜在的な問題を特定して解決したいと思います。

また、「イェーイ、今はうまく機能している！」という肯定的なフィードバックを歓迎します。 同様に、課題追跡システムは通常「課題」でいっぱいなので。 :)

私たちは完全にFedoraでテストする予定です（コメントの前にすでに計画しています）が、火曜日の締め切りはおそらく現実的ではありません。

@hroncok Fedoraがこれらの変更をテストできるようになる時期までに

月曜日はなんとか頑張りますが、約束はできません。

確かに、20.1b1は私たちの問題を解決します。

https://mail.python.org/archives/list/[email protected]/message/5EAUIYYIRKXEHTAG5GQ7EJHSXGZIW2F7/のより一般的な20.1b1フィードバック

やあ！ ベータ版@hroncokをお試しいただきありがとうございます。 とても有難い！ ^> ^

ビルドインプレースの結果の1つ：Pythonの複数のバージョンのホイールを並行して（manylinux dockerコンテナー内で）ビルドしていました。 インプレースビルドでは、異なるバージョンが競合するため、並列ビルドは機能しません。 ツリー外ビルドでは、各バージョンが個別のツリーを作成し、問題はありませんでした。

@mantheyその議論は＃8168の下にあります

ですから、もう10日以上経ちました。 変更に関していくつかの問題が提起されました（すべて私が言うと予想されていました-＃8165、＃8168、＃8196）。 変化が彼らを助けているとはっきりと述べている人々もいました。

• パフォーマンスの問題に加えて、以前の動作（temp dirへのコピー）には、呼び出し元だけが持っているコンテキストの知識がなければpipで修正できない（上記のリンク先の）正確性の問題がありました（補足として、コピーツリーコードはすでにいっぱいでした）奇妙な状況に対処するためのバンドエイド-ツリーのtmpdir、ソケットなど）。
• 以前の動作をアクティブにするオプションには、依然として正確性とパフォーマンスの問題があります。
• 正しい解決策には、現在完全には存在しないビルドディレクトリを制御するためのビルドバックエンドサポートが含まれます（たとえば、setuptools bdist_wheelは--bdist-dirがありますが、それでも.egg-infoを書き込みます場所については、https：//github.com/pypa/setuptools/issues/1816、https：//github.com/pypa/setuptools/issues/1825も参照してください。 したがって、pipが正しく動作するようになったので、たとえば、setuptoolsがソースディレクトリに触れずにビルドを実行するオプションを進化させて、そのオプションを制御するためにPEP 517の変更が必要かどうかを確認するために、議論を変えることができます。
• それまでの間、報告された問題は、呼び出し元が比較的簡単に回避できる可能性があります（たとえば、一時ディレクトリに自分自身をコピーしたり、コンテキストを完全に理解していれば正しく実行できる一時的なtarballを作成したりできます）。
• 最後に、私たちが持っているデータで確実に判断するのは難しいですが、私の直感では、この変更は、それが痛いよりも多くの人々を助けるということです。

だから私は壊れるような変更は嫌いですが、これは軽く行われていなかったので、私は個人的にそれを維持する傾向があります。

私は、新しい振る舞いがピップの振る舞いが「正しく」、確かに異なっており、明らかに場合によっては異なって壊れていることに同意しません。そのようにフレーミングすることは正しくないと思います。 これは、壊れたユーザーの1つのセットと別のセットのトレードオフを表しています。どちらの場合も、実行可能な回避策があります。

私はこの変更をマージせず、それが発生するのを見逃していたか、反対していました（そして、マージしたことで、特定の種類の壊れたパッケージを大幅に防ぐのに役立つ強制関数としてpipを使用するようになると思います）。 そうは言っても、ここで元に戻すことが正しいかどうかはわかりません。 動作が頻繁にフリップフロップすると、ユーザーはさらに混乱する可能性があります。 元に戻す場合は、すぐに行う必要があります。そうでない場合は、現在の動作が良くも悪くもなる可能性があります。

pip wheel <localdir>とpip install <localdir>がcd <localdir> ; setup.py bdist_wheelは異なるホイールを生成する前に、シンボリックリンクが存在する場合に欠落しているファイルが異なるため、「正しく」という用語を使用しました（＃ 3500）、またはsetuptools_scm（＃7549）、 https： //github.com/pypa/pip/issues/7555#issuecomment -595180864、＃6276、またはプレーンエラーのある別のバージョン。 私はpip20.1がそのような悪いホイール/インストールを生成するとは思わないので、その意味でそれは確かにより正しいと信じています。

もちろん、変更によって一部のワークフローが破損することはわかっていました。フィードバックが得られたので、トレードオフを再評価し、元に戻すか、完全に確認する必要があります。

そして、それでもsetup.py sdist && pip install dist/*.tar.gzとは異なるホイールを生成できます。

私の提案は、PRを元に戻し、最初にsdistをシャッフルしてから、結果のsdistからホイールを作成することによって修正を実装することです。

これにより、プロジェクトがsdistを正しく構築できない場合、つまりIMOが解決すべき重要なユースケースではない場合を除いて、すべての正確性の問題が解決されるはずです。

そこでのトレードオフは、それが遅くなるということです。 ただし、それを実装したら、PEP 517インターフェイスをさらに改良して、高速化を可能にするオプションのAPIを追加できます。 それでも、この変更ほど速くなることはないでしょうが、私たちは確かにそれに近づくことができます。

この変更はそのままでは、ユーザーが満足する可能性が低いパフォーマンスの低下を引き起こすことなく、正確さをさらに高めることは事実上不可能になります。 しかし、それを正しくしてからパフォーマンスを向上させると、両者を満足させる幸せな中間点に到達することができます。

古い格言が言うように、最初にそれを正しくし、次にそれを速くします。 私はこのPRで私たちがそれを速くし、それを正しくする私たちの能力を締め出したのではないかと恐れています。

私はまだsdistsの検証が望ましいが、pipのインストール時にはそうではないことに同意します。 多分それは将来のsdistビルダーツールまたはpipビルドコマンドの機能です。

また、 setup.py sdistはローカルディレクトリに.egg-infoを作成するため、読み取り専用のソースディレクトリまたは同時ビルドで報告された問題は残ります。

それがpipのインストール時に発生しない場合、他の誰かのpipのインストール時に機能的には発生しません。 それをスキップするということは、プロジェクトがVCSからインストールされたパッケージに進むことができる複数のパスがあることを意味し、すべてのパスが違いの別のチャンスです。 これは新しいことではありません。基本的に、インストールパスを変更するすべてのオプションは、最も厳密なプロジェクトであっても、ディスク上のバイトセットが異なることになります。 微妙な違いは常に存在し、それらの違いが意味をなさないことを願っています。または、最初からそれらを持たないように構造的に不可能にすることで、それらの違いを取り除くためにできることを行うことができます。

いくつかのパフォーマンスの問題は、sdistを介してビルドした場合に実際に再発する可能性がありますが、おそらくpip <20.1の場合よりも1桁低くなります。 実際、そのほとんどは、 .git 、 venv 、またはsdistにはない他の無関係なボリュームのあるものをコピーすることから生じることがよくあります。

最終的にpip 'がどうなるかに関係なく、どちらかがすべての人を満足させることはできないので、もう一方をオプションにすることはできますか？ 現在のアプローチを維持する場合（どちらをデフォルトにするかについては実際には意見がありません）、ユーザーがsdistを作成してインストールすることを選択できる最終結果のフォールバックを提供できるはずです。そこからのパッケージ。

また、 setup.py sdistはローカルディレクトリに.egg-infoを作成するため、読み取り専用のソースディレクトリまたは同時ビルドで報告された問題は残ります。

私は（少なくとも簡単なテストは私に同意します） setuptools （ distutilsはない）だけがそれを行うと思います、そしてこの振る舞いは他の場所にdirを作成するように構成可能です。 他のバックエンドと同様に、クリーンなsdist生成を行うように推奨できるはずです。

FWIW、generate-sdist-unpack-it-build-wheelアプローチを使用する場合、sdist-generation --egg-infoディレクトリを作業ディレクトリにダンプする必要はないと思います。 generate_metadata場合と同様に、それを一時ディレクトリにダンプします。

@pradyunsgはsetuptoolsの変更を必要としませんか？ 前回チェックしたとき、 sdistコマンドには、 --egg-baseオプションがあるegg_infoとは対照的に、 .egg-infoベースの場所を指定するオプションがありませんでした。 ＃7978で。

それはそう！ setuptoolsで間違ったファイルを見ていました。 🙈私は正直に立っています。

なぜこの空間ですべてがとても複雑なのですか？ :(

$  ls -la
total 8
drwxr-xr-x  3 dstufft  staff   96 May  6 14:26 .
drwxr-xr-x  9 dstufft  staff  288 Apr 28 15:46 ..
-rw-r--r--  1 dstufft  staff   85 Apr 23 16:23 setup.py

$  py setup.py egg_info --egg-base /tmp/foo sdist
/Users/dstufft/.pyenv/versions/3.8.2/lib/python3.8/site-packages/setuptools/dist.py:471: UserWarning: Normalizing '2020.04.23.3' to '2020.4.23.3'
  warnings.warn(
running egg_info
creating /tmp/foo/dstufft.testpkg.egg-info
writing /tmp/foo/dstufft.testpkg.egg-info/PKG-INFO
writing dependency_links to /tmp/foo/dstufft.testpkg.egg-info/dependency_links.txt
writing top-level names to /tmp/foo/dstufft.testpkg.egg-info/top_level.txt
writing manifest file '/tmp/foo/dstufft.testpkg.egg-info/SOURCES.txt'
reading manifest file '/tmp/foo/dstufft.testpkg.egg-info/SOURCES.txt'
writing manifest file '/tmp/foo/dstufft.testpkg.egg-info/SOURCES.txt'
running sdist
warning: sdist: standard file not found: should have one of README, README.rst, README.txt, README.md

running check
warning: Check: missing required meta-data: url

warning: Check: missing meta-data: either (author and author_email) or (maintainer and maintainer_email) must be supplied

creating dstufft.testpkg-2020.4.23.3
copying files to dstufft.testpkg-2020.4.23.3...
copying setup.py -> dstufft.testpkg-2020.4.23.3
Writing dstufft.testpkg-2020.4.23.3/setup.cfg
creating dist
Creating tar archive
removing 'dstufft.testpkg-2020.4.23.3' (and everything under it)

$ ls -la                                        
total 8
drwxr-xr-x  4 dstufft  staff  128 May  6 14:28 .
drwxr-xr-x  9 dstufft  staff  288 Apr 28 15:46 ..
drwxr-xr-x  3 dstufft  staff   96 May  6 14:28 dist
-rw-r--r--  1 dstufft  staff   85 Apr 23 16:23 setup.py

https://github.com/pypa/pip/issues/8165#issuecomment -624669107これは、バグを止めるかなりのショーのように感じ

bdist_wheelは、過去にビルドディレクトリを自動的にクリーンアップするように求められました。 その機能は機能するはずです。他のdistutilsビルドはクリーンですか？

SConsの場合は、気にかけているファイルを記憶し、ファイルシステムに存在していても、build /ディレクトリ内の余分なファイルをホイールから省略します。

上記の問題はmanylinuxだけに影響するわけではない

ビルドディレクトリを自動的にクリーンアップしても問題は解決しません。問題が発生する可能性が低くなります（たとえば、2つのpip wheel呼び出しを並行して実行すると、問題が発生する可能性があります）。このように（少なくともPEP 517の議論では）、インクリメンタルビルドの呼び出し間でキャッシュを許可することにより、パフォーマンスが向上します。 IOWの現在の動作は、一部のサブセットが望んでいたものであり、実行間でビルドアーティファクトを再利用します。これは、最も一般的なビルドバックエンドが非常に間違っていることを示しています（おそらく、場合によっては、パッケージのカスタマイズ）。

もちろん、基になるsetuptoolsコマンドに十分なフラグがあれば、これを修正できます（ py setup.py egg_info --egg-base /tmp/foo build --build-base /tmp/foo/build-base bdist_wheel --bdist-dir /tmp/foo/bdistようなもので解決できます）。

問題は余分なファイルではなく、ホイールと互換性があると予想されるABIが変更され、 .soが再構築されなかったことを繰り返します。 SConsがpymallocでビルドされたPythonが1つのビルドディレクトリを必要とし、Pythonが別のビルドディレクトリでビルドされていることを知っているほど賢い場合（ .soがリンクする可能性のあるNumPyバージョンなどを含む）、影響を受けません。 以前に作成したアーティファクトを別のABIで再利用する場合は、影響を受けます。

ensconsをテストしようとしましたが、エラーなしでrsaletteをビルドすることができませんでした。

scikit-buildをテストして、インクリメンタルビルドがどのように処理されるかを確認しようとしましたが、2番目のビルドで何をしたとしても、それ自体に突き刺さり、 _skbuildディレクトリを毎回手動で削除して取得する必要がありました。エラーなしで実行します。

いいね。 申し訳ありませんが、ensconsは更新されましたが、rsaletteは更新されていません。

2020年5月6日水曜日の午後4時18分、ドナルドスタッフは次のように書いています。

ensconsをテストしようとしましたが、エラーなしでrsaletteをビルドすることができませんでした。

scikit-buildをテストして、インクリメンタルビルドがどのように処理されるかを確認しようとしましたが、2番目のビルドで何をしたとしても、それ自体に突き刺さり、 _skbuildディレクトリを毎回手動で削除して取得する必要がありました。エラーなしで実行します。

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHub https://github.com/pypa/pip/issues/7555#issuecomment-624867490で表示するか、 https：//github.com/notifications/unsubscribe-auth/AABSZERIEDAPUIXCPAKBBUDRQHAXRANCNFSM4KCV5MHQの登録を解除して

申し訳ありませんが、ensconsは更新されましたが、rsaletteは更新されていません。

更新されたensconsを使用する優れたCextはありますか？ rsaletteを選んだのは、それがリストの最初であり、デバッグする気がしなかったためです。他の何かを試してみてください。

rsaletteの唯一の問題は、SConstructのEnvironmentにROOT_IS_PURELIBを渡してはならないことです。 C拡張子はありません。 cryptacularは大丈夫そうです。

＃8165（コメント）

これで、私はこの変更を元に戻すべきであることに同意していると思います。

新しい問題は予想よりはるかに大きいと思います。 おそらく、元に戻すための簡単な20.1.1です。その後、ツリー内ビルドとツリー外ビルドの両方の問題を解決する方法について、より長い議論をすることができますか？

私はまた、これに対する解決策として、 https： //discuss.python.org/t/proposal-adding-a-persistent-cache-directory-to-pep-517-hooks/2303/15を元に戻して追求することに投票し

それは私にも理にかなっているようです。 ツリー内（またはsdistからのビルド）アプローチには、いくつかの非常に重要な利点があると思います（元に戻すと、ユーザーベースの一部から苦情が出ると確信しています🙂）が、欠点もあります重要。

ここでUIをどのようにする必要があるか（デフォルトではどのアプローチにするか、どのようなオプションを使用する必要があるか）はわかりませんが、現在の問題と戦っている間に決定を下すよりも、もう少し時間をかけて決定する必要があると思います。 。

よし！ 一般的なコンセンサスは、元に戻して再評価することだと思います。 このためのPRを提出します。 :)

そこにある提案に同意する場合は、そのスレッドにも参加してください。

お願いします-コメントしてきましたが、意味のある提案ができないところまで来ているので、経験豊富な方からのご意見をお待ちしております。

https://github.com/pypa/pip/issues/8165#issuecomment-625401463にいくつかのbig-blobs-of-textをドロップしました。 今日はもう立ち去ります…最後に個人的なメモを書いていると少しイライラしてしまいました。 最終的に＃5599になり、ユーザーの否定的なコメントを読んでも、確かに役に立ちませんでした。

こんにちは皆さん、私はこれについてもう少し考えました。これがこの問題に関する私の現在の見解です。

1. sdistを所定の位置に構築し、一時的な場所でsdistを開梱して、そこから構築します。

私はまだピップインストール/ピップホイールは悪いsdistsを捕まえるのに適切な場所ではないと信じています。 そもそも悪いsdistsを作成しないというバックエンドの責任ではないでしょうか？ さらに、sdistを介した無条件のビルドは、適切なビルドと同じくらい破壊的だと思います。

1. 所定の場所に構築するためのpipオプションを追加します。

解決策4がうまくいかなかったので、私が最も短期的に好きなもの。 それをpip20.1.1に追加するのは時期尚早ですか？

1. インプレースビルドで「安全」な場合にバックエンドがフロントエンドと通信できるように、何らかのメカニズムでPEP517を更新します。

このピップでは、壊れた修正不可能なコピーツリーにフォールバックする必要があるので、私はこれに賛成しません。

1. ピップを変更して、常に所定の位置に構築します。

したがって、これは破壊的すぎると見なされ、20.1.1で元に戻します。

1. ツリー外でビルドするオプションを使用して、デフォルトでpipをインプレースでビルドするように変更します。

それは長期的な目標であり、キャッシュディレクトリの概念とツリー外のブレンドを構築するオプションである可能性がありますか？

私はCLIオプション、特にこのようなオプションは本当に好きではありません。 ローカルFSにある2つのパッケージをリストし、1つをインプレースでビルドする必要があり、もう1つをビルドする必要がない場合はどうなりますか？ どちらか一方を実行するオプションを提供すると、どちらか一方でしかビルドできない既存のパッケージになってしまいます。

また、プロジェクトが決定を下すことができず、その決定をエンドユーザーにプッシュすることを決定したために完全に存在する種類のオプションのような匂いもします。

sdistを介して構築することは、悪いsdistを捕まえることだけではありません。 大部分は、プロジェクトがインストールされる前に通過できる「パス」の可能なバリエーションを減らすことです。 いくつかの方法でフラグを追加すると、その問題は悪化しますが、良くなることはありません。

つまり、インストールが通過できる「パス」がいくつかあります。

1. VCS-> Sdist->ホイール->インストール済み
2. VCS->ホイール->インストール済み
3. VCS->インストール済み（レガシー）

段階的に廃止されている追加のパスがいくつかありますが、一般的には3つです（理想的には3つも段階的に廃止されます）。 編集可能なインストールもありますが、すぐになくなることはありません。

sdistまたはwheelのいずれかがPyPIにアップロードされ、そこから同じ「パス」の一部になるまでインストールされていると見なすことができます。これは、一時停止して別のコンピューターで終了するだけです。

このような複数の「パス」がある場合の問題は、最終的なインストールで不整合が発生することです。 それらは常に発生するとは限りませんが、頻繁に発生するのは簡単に観察できるケースです。 多くの場合、これらの不一致は大したことではありませんが、大したこともあります。

このようなインプレースビルドを行っている場合、単一のパスに折りたたむことは決してできないと効果的に言っています。この奇妙なエッジケースに常に対処する必要があります。インストールがどのように行われたかに基づいて、人々は異なる結果を得るでしょう。

追加の利点として、これは、ハッピーパスがハッピーであり続けることを保証するための強制機能としても機能します。

ほとんどの場合、 @ dstufftに同意し

しかし、私は1つの点を取り上げたいと思います。

ローカルFSにある2つのパッケージをリストし、1つをインプレースでビルドする必要があり、もう1つをビルドする必要がない場合はどうなりますか？

異なるオプションを使用して、2つのパッケージを2つの別々のpipで実行するだけですか？！？ 一方が他方の依存関係である可能性があることは知っていますが、一般的にはあなたの主張が当てはまりますが、すべてのインストールシナリオを1回のピップにまとめる必要があると人々が考える一般的な傾向があるようです。合理的だと思います（「要件のリストを2つに分割する必要があるため」、問題がユーザーによって拒否される場合の完全に適切な回避策があります）

（もし）元に戻すときは、ツリー内ビルドを実装した結果として閉じられた＃6276のような問題を再度開く必要があることに注意してください。

問題の一部は、依存関係を解決するときにpipがすでにインストールされているものを考慮しないことです（新しいリゾルバーの作業によってそれが変更されるかどうかはわかりません）。したがって、解決する場合は、1回のpip呼び出しにすべてを含める必要があります。依存関係は「正しく」（現在のリゾルバーが正しく実行する範囲で）。

新しいリゾルバーがすでにインストールされているものを考慮に入れる場合、 pip install foo barとpip install foo && pip install barはほぼ等しく、まったく問題になりませんが、そうでない場合（そして今はほぼ同じです）両方のプロジェクトが「スパム」に依存しているが、fooが2未満、barが1より大きい場合、無効なインストールが発生します。

それは接線ですが:)

（新しいリゾルバーの作業によってそれが変わるかどうかはわかりませんか？）

＃7744への入力を歓迎します。 :)

1. ピップを変更して、常に所定の位置に構築します。

したがって、これは破壊的すぎると見なされ、20.1.1で元に戻します。

明確にするために、私たちが「あまりにも早く展開した」こともあり、私たちが採用した展開アプローチは、これがあまりにも破壊的であることになった理由の一部です。

1. 所定の場所に構築するためのpipオプションを追加します。

@dstufft @pfmooreこの種のオプションはオプトインメカニズムであると考えているため、ある時点でデフォルトにすることを目標に、ユーザーをインプレースビルドに向けて段階的に調整できます。 このコメントの精神で： https ：

このためのPRを提出します。 :)

8221です。

20.1.1がリリースされ、元に戻された変更が含まれています。

Fedoraでは、Python RPMパッケージをビルドするとき、私たちは恐竜であり、シンを実行する標準的な方法はpython setup.py buildを使用することです。 PEP 517では、代わりにpip wheelを使用する「暫定的な」方法を追加しました。 ただし、拡張モジュールでは、pipがそれらをビルドするために使用する「ソースをtmpに移動し、そこからビルドする」アプローチに問題があります。

私たちのビルド機構はいくつかのコンパイラフラグを挿入しているので、ビルドアーティファクト（この場合は.so拡張モジュール）にはソースに関するメタデータが含まれています。 後で、ビルドアーティファクトをトラバースし、この情報を抽出し、ソースを/usr/src/debugにコピーして、特別な*-debugsource RPMを介してインストールするシェルスクリプトがあります。 機械はすべてが作業ツリー内に構築されることを期待しており、外部に構築された場合は実際にはうまく機能しません。 これが私たちの側の問題を軽減するために（一緒に）できることです：

1. set the `$TMPDIR` environment variable to have it within the place where the RPM script expects it (i.e. `export TMPDIR=%{_builddir}/.tmp` (and create it))

2. use `pip wheel` with the `--no-clean` option to keep the copied sources in `$TMPDIR`

3. run some shell kung fu to rewrite the "what is my source" information to the correct location: `find %{buildroot} -iname '*.so' -print0 | xargs --no-run-if-empty -0 -n1 /usr/lib/rpm/debugedit -b "%{_builddir}/.tmp/pip-req-build-"* -d "$PWD"`

4. (Optional: clean `$TMPDIR` manually.)

これは事実上、pip統合、＃6505などを検討するときに私が始めた道です。

今日、pipを使用した反復ビルドは事実上壊れています。これは、C拡張形式のPythonコードが大量にあるグループにとって大きな損失であるため、 setup.pyを使用してビルドを呼び出すことにしました。

pip必要buildコマンドの最終結果buildコマンドは次のように、他のサブコマンドに沿って通過可能であるべきであるwheel 、 install 、 NS。

現在、 pipはinstallをbuildおよびinstallとして効果的に処理します。これは、バイナリアーティファクトを構築およびキャッシュし、読み取りを超えてバイナリをインストールする人が望んでいることではありません。 -マウントのみなど。

setup.pyを使用してバイナリを作成し、 bdistを作成せずに、 pip installを使用する方法があればいいのにと思いますが、今日は不可能なようです。 、 pipとdistutils / setuptoolsは、バイナリアーティファクトの場所について合意していないためです。

setup.pyを使用してバイナリをビルドし、bdistを作成せずにpipでインストールする方法があればいいのにと思いますが、pipとdistutils / setuptoolsが合意していないため、今日は不可能のようです。バイナリアーティファクトの場所。

私が従うかどうかはわかりません-あなたはバイナリを使用する方法が欲しいが、すでに存在するバイナリ配布フォーマットを使用したくないと言っています。 何故ですか？

setup.pyを使用してバイナリをビルドし、bdistを作成せずにpipでインストールする方法があればいいのにと思いますが、pipとdistutils / setuptoolsが合意していないため、今日は不可能のようです。バイナリアーティファクトの場所。

私が従うかどうかはわかりません-あなたはバイナリを使用する方法が欲しいが、すでに存在するバイナリ配布フォーマットを使用したくないと言っています。 何故ですか？

bdist形式は非常に制限されています。 私のグループは、tarのようなダム形式に頼って、それを逐語的に解凍する必要があります（BSDはサポートされていない、Debianはサポートされていないなど）。

昨夜私が発見したのは、ダムbdistの使用はpip経由ではインストールできないということです。 ダムバイナリには、 pip 、AFAICTを介してインストールする必要のあるメタデータがありません。ここで、ピップホイールが機能すると思います。

eggとzipも試しましたが、 file:// URIだけを使用してインストールするために必要なメタデータが不足しています。

私はdistutilsを介してビルドを靴べらにし、makeを使用してsetuptoolsをより大きなビルドシステムにしようとしていたので、標準のbdist呼び出しがあります。

https://github.com/pypa/pip/issues/2195#issuecomment -664728481から来てい--use-feature=in-tree-build後ろで＃7882をやり直してよかったと言えます。

フラ！ 計画のようだ！

今回は--buildのdocstringも更新しましょう。 ;）

＃2195（コメント）から来ています。-use-feature= in-tree-buildの後ろで＃7882をやり直してよかったと言えます。

その場合と同様に、コマンドラインで好奇心が強い、持ってするのが妥当だろうin-tree-buildでオプションのセットをpyproject.toml ？ これは、pipをラップするためにbashスクリプトまたはmakefileを作成する必要なしに、＃6276を解決するのに非常に便利です。 （それは特に大きな問題ではありません。）

pyproject.tomlでツリー内ビルドオプションが設定されている

@davidhewittこれは、この問題の元の説明の多かれ少なかれオプション3です。 私の理解では、現在のコンセンサスは、可能であれば追加のオプションを避ける方がよいということです。 したがって、移行期間中に--use-featureを使用してツリー内ビルドを有効にするというアイデアは、デフォルトで唯一のメカニズムにするという長期的な目標を持っています。

ところで、私はこれを20.3に間に合うように実装することはできませんが、それでも、できれば20.4で実装するつもりです。

@sbidoulこの機能を