Pipenv: ロックされた依存関係を1つだけ更新する

これはpipenv installにも役立つ可能性があります。他の依存関係を更新せずに、新しい依存関係をインストールしたい場合があるからです。

ここで考慮すべきことが少しあります。単一の依存関係を変更すると、要件のセット全体が変更される可能性があります。
例： fooを1.0から2.0に更新するには、 barを> = 2.0に更新する必要があります（以前は<2.0でした）など。

pip-tools自体（ pipenvが依存関係解決アルゴリズムを取得する）のコンテキストでは、依存関係解決を実行すると、必要なパッケージが「再ロック」された場合にのみ「更新」されることを知っています。既存のロックファイル。 これは、解決で候補を選択するときに、ロックファイル内の既存のピンが最初に有効な候補であるかどうかを確認することによって行われます。 pipenvはおそらく同じことをすることができます。

それは合理的な考えだと思います。 そうしないと、依存関係を1つだけ更新する場合、依存関係を変更すると他の変更が発生した場合にブロックするモードがpipenv必要になります。そうしないと、有効な環境の保証が失われます。

これがお役に立てば幸いです。

確かに、それは私が意味したことでした：

これにより、my-awesome-depとその依存関係のみの更新を含むPipfile.lockが生成されます。

100％同意します-そしてもう少し先に進みます：これがデフォルトであるはずです。

つまり、 pipenv install fooは、 fooとその依存関係以外には決して触れないでください。 そして、 pipenv lockは確かに何もアップグレードしてはいけません-それはすでにインストールされているものをロックするだけです。

AFAICT、これはnpm 、 yarn 、 gemなどの仕組みです。 実際にパッケージをロックしないロックファイルを用意することは意味がありませんが、パッチのリリースで問題が発生しないようにパッケージの作成者を信頼しているため、要求されることなくアップグレードします。 アップグレードを許可することの使用法を見ることができますが、アップグレードしないよりも驚くべきことなので、オプトインする必要があります。

この問題を他の何かのために乗っ取ってしまったことをお詫びしますが、これはこれから作成しようとしている問題と密接に関連しているため、ここから会話を始めようと思いました。 新しいものを作るべきだと言ってください。

この関連する問題も見つかりました： https ：

pipenv install --upgrade-strategy=only-if-neededを指定できることは、私が探しているもののように思えますが、もちろん、前述したように、pip 10になりつつあるので、これをデフォルトにする必要があると思います。とにかく、envvarは何かになります。

--upgrade-strategy=eagerよりも保守的であるため、その変更が誰かのワークフロー（有名な最後の言葉）を壊すとしたら、私は驚きます。

シェル構成でexport PIP_UPGRADE_STRATEGY=only-if-neededを設定して、これを回避しようとしました。 これは機能せず、 pipenv lockは次の驚くべき動作を示します。

1. アップグレードする必要のないパッケージを「アップグレード」します（ただし...）
2. 実際には、インストールされているバージョンはアップグレードされません。 つまり、 pip freezeとPipfile.lockは異なるバージョンを示しています！

pipenvがインストールのためにpipに委任していると推測すると、pipはその環境変数設定を尊重しますが、 pipenv lockはそうではありません。

@ k4nar望ましくないことがわかった今、どうなりますか？ カスケード要件のある依存関係をアップグレードすると、明らかに他の依存関係に影響が及ぶためです。 _現在のロックファイルのコンテキストで_特定のパッケージの最新バージョンを決定するための何らかのリゾルバーロジックを提案していますか？ すでに複雑でデバッグが難しい解決ロジックに対して、あまりにも多くのハックを奨励することを躊躇しています。

@brettdhあなたがほとんどの作品を持っているので、私はいくつかの光を当てることができると思います。 pipenv lockは何もインストールせず、要求もしません。 ホスト環境、Pythonバージョン、および提供されたPipfile指定した場合にのみ、ロックファイルが生成されます。 他の方法で環境を操作する場合、またはpipを直接使用する場合/ pipenvの外部でpip設定を操作する場合/ pipenv runを使用していない場合、またはpipenvサブシェル内でpip freezeている場合は、非常に簡単です。 pip freezeから同期されていないロックファイル。 この2つは実際には関連していません。

明確にするために：

1. Pipfile.lockは、ユーザーのPipfile基づくpip-toolsリゾルバーを使用して厳密に固定された依存関係の解決です。
2. 1つのパッケージのみをアップグレードしながら、すべての厳密なピンを維持したい場合は、アップグレードしたい1つを除いて、 Pipfile内のすべてを厳密に固定することで、これを実行できると思います（間違っている場合は修正してください） @vphilippon）

あなたのロックファイルとpip freezeが互いに一致しないことについては、もっと情報を知る必要がありますが、システム以外のバージョンのPythonを使用して解決する場合、ロックファイルリゾルバーに関して未解決の問題があると思います。

@techalchemy ：BがAの依存関係である、A、B、およびCのPipfile.lockがある場合、Cを更新せずにAとBを更新できるようにするか、AとBを更新せずにCを更新できるようにします。
もちろん、すべての依存関係とその依存関係をPipfileに固定してそれを行うこともできますが、それを維持するのは負担になります（ほとんどのrequirements.txtがそうであるように）。

@ k4narが書いたすべてに同意します。 確かに、ピン留めすることもできます
すべてをrequirements.txtに入れ、pipenvを使用しないでください。 pipenvのポイントは
それを作る1つのツール（そしてもちろんvirtualenvのもの）を持つこと
管理が簡単。 つまり、すべてのパッケージはデフォルトでバージョンにロックされています
それは機能することが知られていますが、selectをアップグレードするのは簡単なはずです
少数（予期せず他をアップグレードすることなく）。
4:28ヤニックPÉROUXの木、2017年10月26日には[email protected]
書きました：

@techalchemy https://github.com/techalchemy：Pipfile.lockがある場合
A、B、Cで、BはAの依存関係であるため、次のことができるようになります。
Cを更新せずにAとBを更新するか、AとBを更新せずにCを更新します。
もちろん、すべての依存関係とその依存関係を自分の中に固定することもできます
それを行うためのPipfileですが、それを維持するのは負担になります（
ほとんどのrequirements.txtは）です。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/kennethreitz/pipenv/issues/966#issuecomment-339591307 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAFlnqUOEKARiFD8kEk3GVczF3NXBdVOks5swEKcgaJpZM4QEf--
。

うーん、君たちが言っていることがわかります。 設定をpipに渡すという前提は、私​​が心配していることではなく、私が懸念しているpip-toolsで解決しています。 この動作は現在どのようになっていますか？

@techalchemy pip freeze違いを、「 pipenv installインストールするパッケージバージョンは、 pipenv lockがPipfile.lock保存するパッケージバージョンとは異なる」の省略形として言及しました。

確かに、これは、環境変数を介してpipのデフォルトの引数を変更した場合にのみ発生します。 私は、pipenvがバージョンロックではなくインストールのためにpipに委任したのは驚くべきことだと指摘していました。 つまり、インストールされているものをロックするのではなく、インストールする必要があると思われるものをロックします。

質問を少し明確にしていただけますか？ 「pip-toolsで解決する」とは、 pipenv lockが何をしているのか、そしてpipのデフォルトを設定しても影響を受けない理由を指していると思いますか？ また、「この動作」の意味について具体的に教えてください。

@brettdhロックメカニズムには、 pipは存在しない「依存関係の解決」の概念が含まれています。 pip-toolsによって処理されます（つまり、パッチを適用したバージョンで、元のツールとのいくつかの違いをもたらすpipenvによって特別な方法で統合されています）。 つまり、ロックメカニズムはPipfileを読み取り、完全な依存関係の解決を実行して、必要なパッケージとその依存関係によって定義されたすべての制約を満たすパッケージの完全なセットを選択します。

@techalchemy

[...]それは私に関係するpip-toolsで解決しています。

これらの--upgrade-strategyがpip-toolsにどのように影響するかはわかりません。これは、 pip一部の低レベルの内部で機能するためです。 これらのオプションはインストールされているものを考慮に入れているため、これでは期待した結果が得られないと感じています。これは、そのメカニズムで処理されているものではありません。 しかし、ここで実行できるpip-toolsでこれに対する別のアプローチがあります。

「元の」 pip-tools動作は、ロックファイルで必要なもの（コンテキストではrequirements.txt）のみを更新することですが、これはリゾルバーがpipenvに統合された方法で「失われました」。

pip-tools仕組みの履歴書を振り返ってみましょう： https ：
「候補者を選ぶ」の部分を覚えていますか？ これは、 Repositoryオブジェクトをクエリすることによって行われます。
ではpipenv 、私たちが直接設定するPyPIRepositoryについてResolverが、 pip-tools何かを行いますが、それは使用していますLocalRequirementsRepositoryオブジェクトを、その既存のピンを既存のrequirements.txt （見つかった場合）から保持し、 PyPIRepository 「フォールバック」を保持します。

したがって、 pip-toolsでは、候補を選択すると次のようになります。

1. foobar>=1.0,<2.0一致する候補についてLocalRequirementsRepositoryを照会します。
2. 既存のピンがその要件を満たしているかどうかを確認します。
   
   
   
   • はいの場合、そのピンを候補として返します。
   
   
   • そうでない場合は、 proxied_repository （ PyPIRepository ）に候補を照会します。
   
   
3. 返された候補を使用する

事実上、それは既存のピンが最初に試す候補として「優先順位」を与えられることを意味します。

しかし、 pipenvでは、現在、それは単に：

1. foobar>=1.0,<2.0一致する候補について、 PyPIRepository （直接）クエリします。
2. 返された候補を使用します。

したがって、 pipenvのロックについても、 Pipfile.lockを解析して既存のピンを取得し、 pip-toolsようにLocalRequirementsRepositoryを使用することで同じ動作を実行できると思います。 pip-toolsはpip-compileコマンドで実行します。

@vphilipponそれを実装するのがどれほど難しいかを感じますか？

@techalchemy

• Pipfile.lockを解析して既存のピンを抽出する：それを見たことがありません。 pipenvで物事がどのように構成されているかによって異なります。 Pipfile.lockのピンを表すInstallRequirementsセットが必要です。
• LocalRequirementsRepository ：かなり簡単：現在のPyPIRepositoryをLocalRequirementsRepositoryます。

しかし、これを調べて、 フォローしていると、いくつかのことに気付きます。

1. 現在のデフォルトのpipenv install動作は、 pipenv lock動作と一致しません。 pipenv install requests単独で実行しても、新しいバージョンがリリースされた場合、 requestsは更新されません（ストレートpip install ）。 ただし、 pipenv lockを実行すると、 Pipfile指定子に一致する最新バージョンのrequestsと依存関係の制約でPipfile.lock pipenv lockが更新されます。
   これを確認する主な方法は2つあります。
   
   
   
   • A） Pipfile.lockは、現在の環境のように維持し、環境を変更した場合にのみ変更するために、デフォルトで可能な限り安定した状態を保ち、必要な場合を除いてピンを変更しないようにする必要があります。
   
   
   • B） Pipfile.lockは、 Pipfileとlibの依存関係のオープンレンジから自由に利益を得るために、環境の制約/依存関係を尊重する最新バージョンを取得する必要があります。これにより、で新しい互換性のあるバージョンを継続的に取得できます。あなたの環境。 その後、 pipenv updateを実行して、新しいロックを利用できます。
   
   

IMHO, I would align the default behavior, which would be to go with A) by default. Because right now, everytime a lock is performed (i.e. after each installation), new versions can come in, which make the lockfile *drive the update of the environment*, which seems weird. But, this is arguable of course. While in development, I might want to continuously update my requirements to no get stale, like with B), so that should also be easily doable.

1. 正しい既存のピンの更新を回避するためにLocalRequirementsRepositoryを使用し、最終的にデフォルトの動作を調整する場合でも、ロック部分の--upgradeおよび--upgrade-strategyに相当するものに対処する必要があります。 。 現在、いくつかの環境変数（ PIP_UPGRADEやPIP_UPGRADE_STRATEGY ）を定義すると、 pipenv install動作に影響しますが、 pipenv lockには影響しないため、影響しません。 pip-tools （最初はわからなかったので、確認しました）。
   そうしないと、 Pipfile.lock削除する（不格好で「オールオアナッシング」と感じる）か、新しいバージョンを要求する（つまり、明示的なpipenv install requests>2.18.4実行する）ことなく、環境を更新する方法はありません。これは、新しいバージョンが出ていることを知っている必要があり、 Pipfile自体の指定子を変更して、下限を増やします）、これは間違っています。 「元のpip-tools 」はこれに対処するためにpipに依存しないため（現在インストールされているものとは関係がないため）、更新する依存関係を指定するオプションを提供します。ロックファイルを作成し、これらのパッケージ（またはすべて）のピンをexisting_pinsリストから削除するだけで、PyPIのクエリに効果的にフォールバックできます。 「--upgrade-strategy」の概念をこれとどのように一致させることができるかわかりません。

@techalchemy
したがって、「デフォルトの動作を調整する」のはかなり簡単だと言っていましたが、これにより、パッケージを更新できるという大きな問題が発生することがわかりました（たとえば、現在の制約に一致する最新バージョンをフェッチするだけです）。 。

不明な点がある場合は、質問してください。これを書くときに多くの編集が行われました。

（依存関係の解決は簡単ではありません。適切で実用的な依存関係の解決は最悪です😄）

@vphilipponそれはまさに私が意味したことです。 解決されたロックファイルを使用してインストールを実行し、プロセスを逆方向に駆動しない限り、pipがインストールするものをpip-toolsが解決するものと同期させることは簡単ではありません。 それが、物事がそのように設計された理由であると確信しています。

B）Pipfile.lockは、環境の制約/依存関係を尊重する最新バージョンを取得して、Pipfileとlibの依存関係のオープン範囲から自由に利益を得て、環境内の新しい互換性のあるバージョンを継続的に取得できるようにする必要があります。 その後、pipenv updateを実行して、新しいロックを利用できます。

このワークフローは、現在の構成で機能する可能性があります。 pipenv lockを使用してロックファイルを生成できますが、 pipenv updateは環境全体を再インストールします。 さまざまな出力形式の1つを使用して、依存関係グラフを解決し（ご存知のように、すでにjson形式があります）、ロックファイルに整列しないものだけを再インストールできると確信しています。 これはもっと賢明かもしれませんが、決定を下す前に@nateprewittまたは@erinxoconの入力について知りたいと思います

@vphilipponAとBがさまざまな状況で望ましいワークフローであることに完全に同意します。 Bの周りの言い回しのいくつかは私を少し混乱させましたが、 pipenv lockは実際には環境と一致しないロックファイルになる可能性があると言っているようです-特に、「 pipenv update実行する必要がある」という点でこれを聞きました

AワークフローとBワークフローのどちらを使用しているかに関係なく、私にはいくつかのことが一定しているように見えます。これは、 @ techalchemyが言っていることとも

• pipenv lockの結果は、常に環境に一致するロックファイルである必要があります。
• pipenv installの結果は、常にロックファイルと一致する環境である必要があります。

実装の詳細は無視していますが、これは、ロックファイル機能を備えたパッケージマネージャーに期待するベースラインの動作の一種です。

pipenv update定期的に実行すると、すべてを最新の状態にしたい限りBモードを維持できます。また、 pipenv install --upgrade requestsを実行できると、パッケージに影響を与えることなく、1つのパッケージとその依存関係を特定に更新できます。不必要にアップグレードする必要はありません。

ユースケースがありませんか？ Bの最適化（たとえば、常に熱心に更新するように指示するフラグまたはenv変数）を考えることができますが、これで基本をカバーしていると思います。 私はあなたがすでにカバーした地面をリトレッドしていることも知っています。 あなたが話していることを私が確実に理解することは私にとってただ役に立ちます。 :)

Bの周りのあなたの言い回しのいくつかは私を少し混乱させました、しかし、pipenvロックは実際には環境と一致しないロックファイルをもたらすかもしれないと言っているようです

@brettdhこれは正しいです- pip-tools我々が生成するために使用するリゾルバPipfile.lockパッケージがインストールされているかのリストについてvirtualenvのを聞いていません。 代わりに、 Pipfileのピンのリストで指定された条件を満たすパッケージのリストをコンパイルします。 リゾルバー自体はシステムまたは外部のpython / pipenv / pip-tools installを使用して実行されるため、virtualenvで使用されているのと同じバージョンのpythonでパッケージを解決するように説得するためにいくつかの最高の策略を行っています。 pip installでも同様に問題が解決されると想定されますが、それが常に当てはまるとは限りません。 ただし、はい、 pipenv lockはvirtualenvに基づいて生成されるのではなく、 Pipfile基づいて生成されます。 これは依存関係解決ロックファイルであり、環境状態ピンではありません。

これに対する潜在的な解決策として：pip自体が現在サポートしているが、 pip-compileがサポートしていないものは、制約ファイルの概念です。

制約ファイルは、「このコンポーネントがインストールされている場合は、このバージョンの制約を満たす必要がある」という点で要件ファイルとは異なります。 ただし、制約ファイル内の特定のパッケージが依存関係ツリーのどこにも表示されない場合、そのパッケージはインストールされるパッケージのセットに追加されません。

Pipfile.lock世代への必要な入力は次のとおりであるため、これは現在pipenvにない機能です。

1. 新しい要件入力ファイルとして更新されたPipfile内容
2. 現在のコマンドで具体的に指定されているパッケージを除く、制約ファイルとしてのPipfile.lockからの既存の依存関係のフルセット

pip-toolsリゾルバーレベルでの制約ファイルのサポートは、依存関係の暗黙的なアップグレードの試行が制約違反として失敗するモードをサポートするのにpipenvで十分であり、ユーザーは追加するかどうかを決定できます。更新されるセットへのそのパッケージ。

現在サポートされていません、フィードバックに感謝します

@kennethreitz

どういう意味ですか：

1. この動作は変更する必要がありますが、現時点では優先事項ではありません。
2. この動作はオプションとして追加する必要がありますが、現時点では優先事項ではありません。
3. この動作を追加しないでください。

これは、他の同様のロックパッケージマネージャーの動作との不一致を考えると十分な不便であり、PRの勧誘としてこれを開いたままにしておくとよいでしょう。

代わりに（3）であり、これが追加されない場合、この問題に関する多くの人が、Pythonパッケージ管理ツールの選択について計画を調整する必要があると思います。

これは現在サポートされていないことを意味し、フィードバックに感謝します。

サポートされていないことを理解しています。 また、この動作を変更したり、オプションとして追加したりするPRを受け入れないと言っていますか？

何も思いつきません。

@ k4narはまだこのためのPRをすることに興味がありますか？ 具体的には、 pipenv install --only <dep-to-updateようなもので、無関係の部門が更新されるのを防ぎます。 @kennethreitzはこれひいては、 pipenvを使い続けることができるかどうか）を知る唯一の方法だと思います。

興味はありますが、これを実装するための最良の方法がわからないのです。 動作中のコンポーネントはたくさんあり（pip、pip-tools、pipfile、pipenv…）、おそらく多くの可能な解決策があります。

https://github.com/kennethreitz/pipenv/issues/966#issuecomment -339707418によると、比較的簡単なはずです。 そのdep解決ロジックは、主にpip-toolsからのものです。 PRを提出することを計画していましたが、コードの記述に時間を費やす前にAPIをどのように表示するかについて話し合いたくない場合は、作業に費やすことを正当化できません。

私は現在、別のアプローチを取ることを検討しています。Pipfileは標準であるため、Pipfileとのやり取りは、pipenvを経由する必要はありません。ここでは、 httpsごとに既存のvirtualenvをワイプするなど、他の奇妙なセマンティクスのいくつかを回避したいと思い

クローズされた問題についてコメントして申し訳ありませんが、私の理解では、プロジェクトでpipenvを使用するには、現在次のようなワークフローが必要であることを指摘しておきます。

pipenv install foo
vim Pipfile.lock  # Manually remove all the unwanted updates
git add && git commit && git push

これをチームメンバーに伝えなければならないのは本当に面倒だと思います。 別の方法は、すべてをPipfile正確なバージョンに固定することのようですが、そもそもそれは、pipenvを使用する目的の多くを無効にします。

IIUC、この動作は、 apt install fooを実行するたびに暗黙のapt dist-upgradeを実行するapt install foo aptと同等です。

これは、 pipenv installがPipfile.lock内のものを更新するが、ローカルvirtualenvに更新をインストールしないという事実によってさらに悪化します。 開発者がPipfile.lockの差分を注意深く調べない場合でも、ローカルで古いバージョンを使用していますが、コードを共有すると、他のすべての環境で驚くべき更新が行われます。 Pipfile.lockは自動生成されたファイルと見なされるため、人々は

「 Pipfile許可されている最新バージョンにすべてを更新する」は、「installfoo」とは別の明示的に要求された操作である必要があると強く確信しています。

マスターで修正する必要があります

動作はまだ存在します。 pipenv 11.8.3 、@ kennethreitzでテストしました。

@ marius92mc 「マスターで修正済み」コメントは、最近のリリースで追加された--selective-upgradeおよび--keep-outdatedオプションをhttps ：//docs.pipenv.org/#cmdoption -pipenv-install-keep -時代遅れ

これにより、アップグレードが発生したときにその動作を正確に制御する必要がある、または必要とする人々が、 OWASP A9を尊重し続け、あらゆる機会に熱心なアップグレードを推進することができます。

@ncoghlan必要なことの1つ（要求するのは簡単ですが、実行するのは簡単ではありません）は、これらのオプションの動作に関するFAQです（少なくとも私にとっては混乱を招きます）。

例： --selective-upgradeと--keep-outdatedを使用すると、更新する「選択した」パッケージに直接関連していない場合でも、 Pipfile.lock内の古いライブラリが更新されます。 。

それなら、実装のバグがあるようです。

これらは、新しい変更を除いて、pipfile.lockをそのままにしておくことを目的としています。

テストPipfile + .lockを提供することが役立つかどうか教えてください。

あなたは私たちが調査するのに十分な情報を提供したと思います。 今からやってみます。

実際、古い結果が含まれている場合は、pipfile / lockが最適です。

@ncoghlan 、詳細を提供していただきありがとうございます。
上記のオプションを使用して再試行しましたが、結果は同じようですが、他のパッケージも更新され、 Pipfile.lockファイルで変更されます。

@kennethreitz https://github.com/simonpercivall/pipenv-selective-upgrade-test

この問題に関する更新はありますか、@ kennethreitz？

これについての遅い答えでごめんなさい。 ここではまだリグレッションの根本原因を特定していませんが（私は今週末にデータセンターの移行を個人的に処理しているので、少し時間がかかりました）、数日中にこれを分類します。

貢献はいつものように歓迎します！

これと同じ変更を使用できるユースケースが欠落していると思います。アプリケーションを開発しているときに、単一の依存関係のバージョンをアップグレードする必要があることがよくあります。 私が従いたいステップは次のとおりです。

1. setup.pyの依存関係のバージョン制限を更新します
2. pipenv lock --selective-upgrade ; pipenv syncまたはpipenv install --selective-upgrade "-e ."いずれかを実行します

@wichert Pipfileが、現在のロックファイルにあるものを超えて最低限必要なバージョンを増やすように編集されている場合、 --keep-outdatedはすでに必要なものをカバーしているはずです。 --selective-upgradeは、 Pipfileが変更され

@ncoghlan Pipfileはこのシナリオでは変更されていません。依存関係の最小バージョン要件を変更することで、 setup.pyのみが変更されます。通常は、より新しいものに変更され、現在はPipfile.lockます。

@wichert pipenvは、setuptoolsではないため、 setup.pyへの変更を自動的にキャプチャしません。 それを実現したい場合は、 pipenv lockを実行する必要があります。

これの現状はどうですか？ 3月25日、誰かが実装の問題は「数日以内に」解決されると考えていると述べ、他のバグレポートはここで追跡されたためクローズされました。 しかし、2018.7.1の時点で、Simon Percivallによって報告されたバグがまだ表示され（間接的な依存関係は常に更新されます）、そのバグは元のレポート以降議論されていません。 問題はまだ追跡されていますか？

（私は現在セネガルの第2層都市に住んでいるので、インターネットはひどいです。可能であれば、間接的な依存関係の更新でデータの上限を超えないようにするのはゲームチェンジャーになるでしょう：P）

PS：Pipenvを作ってくれてありがとう、それはすごい<3

はい、確かに。 現在、これをサポートするためにリゾルバーを書き直しています。 このリリースまたは次のリリースのどちらに到達するかはまだわかりません

私は、リゾルバーがいつ着陸するかを見積もるコーディングスキルにそれほど自信がありません：p真剣に、これは完全にボランティアのプロジェクトであり、商用環境の場合のように期限メカニズムはありません（上司やプロジェクトマネージャー、または何かを行う必要がある時期を決定する会社内のあらゆるもの）。 あなたが望む時間枠で物事を成し遂げたいのなら、あなたはそれを自分でやる必要があります、あるいは少なくとも他の人にそれをする本当の動機を提供する必要があります。

@uranusjr FWIW、上記の@benkuhnのコメントには、便宜性の要求は見られませんでした。物事がどこにあるかについての質問です。 つまり、外部のオブザーバーが独自の見積もり/決定を行うことができるように、どのような作業が行われたか。

pipenvはボランティアプロジェクトであり、非寄稿者は、サインアップせずに日付までに行うことを要求できないことを理解しています。 プロジェクトの開発プロセスに透明性を高める余地があるのか​​、それとも適切な場所を探していないだけなのか、疑問に思います。 通常、答えは「問題が更新されていない場合、動きがない」または「このWIPプルリクエストを見てください」のいずれかですが、特にこの問題ははるかに大きな努力を引き起こしたようであるため、ドットは難しい場合があります直接関与していない人のために接続します。

いつものように、pipenvの改善に向けて貴重な時間を割いてくださった皆さんと皆さんに感謝します。 👏

確かに、これはそれよりもはるかに複雑なので、活動や進行中のPRはありません。 私たちは主に、より大きなプロジェクトに関してこれをどのように構築したいかについて社内で話し合っており、適切に機能し始める可能性のあるアプローチを確立するために繰り返し取り組んでいます。 それを整理できたら、解決ロジックを構築できます。

その間、pipenvのリゾルバースタックは非常に複雑であり、この目的のためにそれを解きほぐすためにあまりにも多くの努力を投資するように人々に求めるのは気が進まないでしょう。 ここでの最も単純なユースケースでさえ、大幅なリファクタリングが必要になります。 誰かがこれに取り組むのを手伝うことに興味があるなら、提案されたリファクタリングをレビュー/議論させていただきますが、2つのことは密接に関連しています。

誰かが依存関係の解決と座った解決の専門知識を持っているなら、私たちは確かにインプットに興味があるでしょうが、具体的なアイデアはまだ1つもありません。 私たちは、概念実証以上のものとして持ち越すことを計画していなかったいくつかの反復を経験してきました。 すべてのコードがPRになるわけではなく、すべてのコード編成の決定が課題追跡システムで行われるわけではありません。 時々、私たちは同期してチャットし、リアルタイムでアイデアを提案して廃棄します。

これに対処する可能性のある代替ワークフローとして私が提案したことは、インストール時に_Pipfile_内の特定のバージョンに簡単に固定できるようにすることです。

pipenvがfoo = "*"を「fooの_some_バージョンがインストールされていることを確認する必要があるだけで、ユーザーはどちらを気にしない」という意味に解釈するのは少し驚くべきことですが、完全に不合理ではないと思います。 以下のようなそのために、持つ何かpipenv install --pin fooでその結果がfoo = "==1.2.3"の代わりにfoo = "*" （1.2.3がfooの現在の最新バージョンです）Pipfileではそれがかもしれないように思えます助けて。

ただし、これに関する問題は、多くのパッケージの動作が依存関係に基づいて大きく変化する可能性があり（たとえば、同じバージョンのpylintは、使用しているアステロイドのバージョンに応じてまったく異なることを実行できる）、パッケージはそうではないことです。自分の部門を正確に固定します。 ですから、これが実際に誰かを遠ざけるとは思いません。 ：/

（私が間違った問題にコメントしていることに気づきました。混乱してすみません、私を無視してください）😞

私がここ数時間苦労してきた実際のユースケース：Django2.0プロジェクトのテストカバレッジを測定したいと思います。 pipenv install --keep-outdated --selective-upgrade --dev coverageさえ、非開発のDjangoパッケージをバージョン2.1に更新することを主張していますが、他の場所で破損しているため、まだ絶対に使用できません。 完全に無関係なパッケージを壊れている可能性のあるバージョンにアップグレードせずに、インストールされているパッケージのセットを変更する方法が本当に必要です。 最新バージョンでの破損の可能性は常に存在します。

@rfleschenbergの回避策を試してみますが、おそらく正しくない_meta hashプロパティがあると何かが壊れるかどうかはわかりません。

@ l0b0アプリケーションが本当に特定のバージョンのDjangoを処理できない場合、

@AlecBenzerそれは私にはsetup.pyのための何かのように聞こえます。

@wichertそれも理にかなっているかもしれませんが（実際には、setup.pyとPipfileの両方が必要な状況については完全にはわかりません）が、Pipfileに次のような行がある場合：

Django = "*"

あなたはpipenvにDjangoの_any_バージョンをインストールしたいことを伝えています。 本当にやりたいことが2.0以下をインストールすることである場合は、代わりに次のように伝えてください。

Django = "<=2.0.0"

この特定のケースでは、pipenvは本当の理由なしにDjangoをアップグレードしていますが、Django> 2.0.0を必要とするパッケージをどこかでインストールしようとしている可能性があります。その時点で、pipenvは、指示がない場合は喜んでインストールします。 <= 2.0.0が必要です。

本当にやりたいことが2.0以下をインストールすることである場合は、代わりにそのことを伝えてください

@AlecBenzerを振り返ってみると、これがパッケージをインストールするときにデフォルトでnpm / yarnが行うことであることが^major.minor.0を指定します。これにより、最新へのアップグレードが明示的に要求された場合でも、予期しないメジャーバージョンのアップグレードが防止されます。 Pipenvも同じことをすべきかどうか疑問に思いますが、それは別の問題になります。

もちろん、それらのロックファイルは、マイナーバージョンやパッチバージョンでさえ偶発的なアップグレードを防ぎます。これはここで要求されていることです。

上や他の場所で議論されていると思いますが、npm / yarnとpipenvの間のデザインスペースには緊張/トレードオフがあります。 パッケージマネージャーは、表面上はこれらの目標を持っていますが、いくつかの相対的な優先順位があります。

• パッケージのインストールとアップグレードを簡単にします
• 誤った依存関係のアップグレードで誤ってアプリを壊さないようにする

Pipfileに正確なバージョンを固定する際の問題は、パッケージのアップグレードが難しくなることです。 これがpip-toolsが存在する理由です（requirements.txt用ですが）。

--keep-outdatedフラグは、問題が再開されたときに述べられたように、意図したとおりに機能していないようです。 その動作をデフォルトにするかどうか、および他のパッケージマネージャーとどのように連携するかは、ここでは実際には中心的な問題ではありません。 最初に問題を修正しましょう。

@brettdh

振り返ってみると、これがパッケージをインストールするときにデフォルトでnpm / yarnが行うことであることがわかりました。 彼らは最新のmajor.minorバージョンを見つけ、package.jsonで^ major.minor.0を指定します。これにより、最新へのアップグレードが明示的に要求された場合でも、予期しないメジャーバージョンのアップグレードが防止されます。 Pipenvも同じことをすべきかどうか疑問に思いますが、それは別の問題になります。

ええ、それは私がhttps://github.com/pypa/pipenv/issues/966#issuecomment-408420493で提案しようとしていたことの線に沿ってい

これが取り組んでいるのを聞いて本当に興奮しています！

それまでの間、 pipenv lockを実行して、適用したくない結果のロックファイルの変更を手動で元に戻すよりも、手間がかからず、エラーが発生しにくい回避策が提案されていますか？

@benkuhn私が知っているわけではありません-私はいつも同じロックをしてダンスを元に戻します。

ああ、少なくとも時々、手で元に戻すのを避けることができます：

1. pipenv lock
2. git commit -m "FIXME: revert"
3. pipenv install packagename
4. git commit -m 'Add dependency on packagename'
5. git rebase -i
6. FIXME: revertコミットを削除します

残念ながら、 Pipfile.lock 、 packagenameの要件を満たすには古すぎるバージョンのパッケージが含まれている場合、一貫性のないPipfile.lockを作成することは可能ですが、おそらくpipenvは文句を言います。それが起こった場合、これについて？

--keep-outdatedは、Pipfileで指定された（固定されていない）明示的な依存関係のみを体系的に古くし、暗黙的な依存関係はすべて更新されているようです。

他の依存関係を更新せずにpipenv==2018.7.1を使用して単一の依存関係を更新/インストールすることはできないということは正しいですか？ --selective-upgradeと--keep-outdatedさまざまな組み合わせを試しましたが、成功しませんでした。

Pipfile.lockを手動で編集するのは楽しいことではありません...

@ max-arnoldと同じように、既存のプロジェクトでツールを使用するのは初めてです。本当にがっかりしていると言わざるん。使用を開始する前に、ドキュメントサイトとビデオデモを確認しました。印象的pipまたはpipenvでの作業はほとんど同じです、私が持っている場合、スレッドで他の多くの人が言っているように、私はポイントがわかりませんロックファイル、更新する必要がないのに他の依存関係を更新する理由。

もちろん、###更新が必須の場合は、必要なすべての依存関係を更新しても問題ありませんが、それらだけで、すべてが古くなっているわけではありません。

また、オプション--selective-upgradeと--keep-outdatedは何に役立つのか明確ではありません。これを強調する別の問題があり、＃1554であり、これらのオプションの機能に誰も応答できません。

しかし、私の主な失望は、このパッケージがPythonの公式ドキュメント自体pipに固執するだけでも、これらの問題は解決されませんが、少なくともそれは非常に最小限であり、ほとんどすべての環境に含まれています（追加の依存関係は追加されません）。

@mrsarmご意見ありがとうございます。 申し訳ありませんが、うまくいきません。 しかし、失望がどこから来ているのかわかりません。 誰もPipenvを誰かに強制していません。 それがうまくいかない場合は、使用しないでください。 これが推奨事項の仕組みです。

あなたの暴言もこの問題に特に関連するものは何もありません。 物事がうまくいかないときに人にゴミを捨てないようにするには、少し自制心が必要だと思いますが、敬意を表して、そうすることは控えてください。

@uranusjrそれはゴミではなく、意見であり、私の場合のように、誰かが私が今働き始めたプロジェクトを作成するためにpipenvを選んだ場合、それはオプションではありません、そして私はこれに対処しなければなりません。

しかし、事態は今最悪になり、私が言うことは意見ではなく、事実です。

この問題に対処することを避けるために却下した依存関係を1つ追加しようとした後（これは開発依存関係であるため、 pipと古いrequirements-dev.txtアプローチを使用して2番目の環境を作成しました。そのツール）、別の依存関係を追加する必要がありました。

新しい依存関係はPyYAML、たとえば最新バージョンです。 pipを使用して新しい環境にインストールすると、ライブラリに依存関係が追加されないことがわかります。したがって、PyYAMLのみがインストールされます。これらの場合、Pipを使用すると非常に簡単です。 PyYAMLとは、任意の依存関係を持っていない、そしてそれは以前、プロジェクト（旧バージョン）にインストールされていないにもかかわらず、しかし、（私が作成していないというプロジェクトがPipenvで管理されているため）Pipenvと同じ問題を依存関係を追加すると、起こっpipenvは、ロックファイルと仮想環境内のすべての依存関係を更新しますが、他の依存関係を更新したくありません。依存関係のない1つの新しいモジュールを追加するだけです。

したがって、結論（そして、pipenvがすべての依存関係を壊したという事実ではなく、意見）は、依存関係の管理に対処するのを助ける代わりに、Pipenvがそれを地獄に変えるということです。

私はこのスレッドを何ヶ月もフォローしてきましたが、実際のプロジェクトでは最終的にこの問題に遭遇すると思います。これは、動作が予期せず、直感に反し、危険であるためです。

約1か月前、 pipenv 、 poetryより包括的な代替手段を試しました。 解決する必要のある問題を解決しました。
1）1セットの依存関係（setup.py、setup.cfg、pip、およびpipfile-> pyproject.toml）を管理する
2）将来志向で、下位互換性があります（ここでもpyproject.toml ）
3）かなり意見がない（
4）そして古典的なPipenv問題の解決策：「また、新しいパッケージをインストールするときにロックされたパッケージを更新しないように[pipenv]に明示的に指示する必要があります。これがデフォルトである必要があります。」 [[1]（https://github.com/sdispater/poetry#what-about-pipenv）] [[2]（https://github.com/pypa/pipenv/issues/966#issuecomment-339117289）]

私はpipenv問題についてこれらの考えを共有することを検討しましたが、

• 免責事項として、私は詩チームのメンバーでいません。

ps Pipenvが「公式」ソリューションであるという懸念は、ファーストクラスの統合によるものだと思います。 @ uranusjrは、これを単純な推奨事項と見なしています。フォワード」。 率直に言って、その推奨は、1年以上前から存在している特定のPEPよりもコミュニティで信頼できるものです。

誰もあなたに私たちの課題追跡システムへの参加を強制していません。 生産的なコメントがない場合は、トリアージの問題を対象としていないフォーラムを見つけてください。

代替のリゾルバー@uranusjrを試すことに興味があり、私が数週間実装しているユーザーは、互換性のあるhttps://github.com/sarugaku/passaを試してみて

これは私たちが空き時間に管理するプロジェクトです。 何か修正されたものを見たい場合、またはより良いアプローチがある場合は、喜んで寄付を受け付けます。 あなたが私たちがあなたの日とあなたのプロジェクトを台無しにしたと単に私たちに言うためにここにいるなら、私はあなたに一度だけあなた自身を見るために頼むでしょう。

この問題を忘れたり無視したりしていません。上記のリゾルバーに修正が完全に実装されています。 忍耐を持って、礼儀正しく、または他の場所で話をしてください。 修正を辛抱強く待っている人は、上記のリゾルバーを試してみてください。ニーズに合っているかどうかを確認したいと思っています。 適切なバックトラックと解決を実装しており、このアップグレード戦略を処理するべきではありません

短期的には、最初に切り詰めなければ、このためのバンドエイドをpipenvに入れることができると思います。

@dfeeアプリケーションとライブラリの間の境界線をぼかすことが依存関係管理の正しい答えであるかどうかはよく

@techalchemy

アプリケーションとライブラリの間の境界線を曖昧にすることが依存関係管理の正解であるかどうかはよくわかりません。そのため、詩のアプローチが利点であるとは思いません。

なぜですか？ ライブラリとアプリケーションの依存関係を別々に管理する必要があるというこの考えを私は理解していませんでした。 2つの違いは、アプリケーションが再現可能な環境を確保するために必要なロックファイルだけです。 それ以外は同じです。 これは他のほとんどの言語の標準であり、Pythonは何らかの理由でここでは例外のようです。これは、物事を本来よりも複雑にしているため、ユーザーエクスペリエンスの観点からは悪いことです。

また、制限と問題自体があります

どれ？ Poetryの使用中に発生した問題や制限について本当に興味があります。

とても失礼な豆に謝罪します。 コメントを読んで、私が提供した情報といくつかのオプションがまだ有効であるにもかかわらず（IMHO）、私が言いたいことを書いた方法が適切ではなかったことに気づきました。

課題追跡システムは、バグや改善点について話し合う場所であると理解しています。これがバグなのか、設計上のエラーなのかについては、スレッドでは明確ではありませんが、申し訳ありません。

ここには2つの強力なトピックがあると思います。

• 新しい依存関係をインストールしようとしている場所で、古い依存関係をすべてpipenvで更新する必要があります。インストールしようとしている新しいパッケージ/バージョンは既存の依存関係で機能するため、更新する必要はありません。インストールしようとしている新しいパッケージの依存関係はありませんか？ これはこのチケットの範囲外かもしれませんが、議論することは非常に重要なトピックです。
• これらのパラメータの1つ--keep-outdated --selective-upgradeにより、これらの動作を回避できますか？ これらのオプションが何をするのかは明確ではなく、それらに関するドキュメントが不足しており、関連する問題（＃1554）でも誰もそれに答えていません。

これらのパラメータ--keep-outdated --selective-upgradeいずれかにバグがある場合でも、依存関係の不要な更新を解決するパラメータをデフォルトとして設定しないことは、本当に悪い考えです。

同様のシナリオと比較するために、 apt-get install vimを実行してvimツールをシステムにインストールすることを想像してください（必要なvimの依存関係または更新が適用される場合）が、この状況でも想像してくださいaptは、システムの他のすべての依存関係を更新します：python、QTシステム、Linuxカーネル...など。 aptで他の依存関係を更新できないわけではありませんが、それを行うための明確なコマンドがあります： apt-get upgrade 、 apt-get install PACKAGE PACKAGEとその依存関係をインストール/更新するだけです。

@sdispaterの区別は、これまでに経験したすべての意見の不一致の中心であり、非常に微妙ですが、 https： //caremad.io/posts/2013/07/setup-vs-requirement/または良いものを紹介します。エリクサーのユースケースに関する記事： http ：

pyproject.tomlは、ライブラリ定義メタデータでは実際にはサポートされていません。また、信頼できるものとしてpeps 517および518（どちらもまだ実装の詳細が解決されている）を実装していないpipのバージョンではまったくサポートされていません。ライブラリ宣言ファイル。 setup.cfgはその目的のために存在し（ setup.pyの実際の後継）、IMHOは両方とも実際にサポートされている必要があります。 ライブラリは公開されており、他の人とサンドボックスでうまくプレイできるように、抽象的な依存関係で使用することを目的としています。 アプリケーションは通常、大きくて複雑な獣であり、時には何百もの直接的な依存関係があります。 したがって、私たちの主な相違点の1つは、ツールを設計および構築するときに、これも考慮に入れることです。

@mrsarm最初の質問では、更新の動作は意図的なものでした（当時、/ cc @ncoghlanで広く議論され、OWASPのセキュリティ上の懸念に関連していました）。 2番目の点では、動作が現在適切に実​​装されていないため、問題がまだ発生しているため、前述のpipenvの背後にあるバッキングリゾルバーを書き直すことになりました。 それは単にこの振る舞いをサポートしていませんでした。 --selective-upgradeは、新しいパッケージの依存関係であるものだけを選択的にアップグレードすることになっていますが、 --keep-outdatedは、新しいパッケージに必要な依存関係を満たすものをすべて抑制します。 少し異なりますが、現時点ではどちらも正しく機能しないと確信しています。

pyproject.tomlは、ライブラリ定義メタデータでは実際にはサポートされていません。また、信頼できるライブラリ宣言ファイルとしてpeps 517および518（どちらもまだ実装の詳細が処理されている）を実装していないpipのバージョンではまったくサポートされていません。 。 setup.cfgはその目的（setup.pyの実際の後継）のために存在し、IMHOは両方とも実際にサポートされている必要があります。

まあ、これは確かに話題から外れていますが、それは重要な議論なので、私は自分自身を助けることはできません。

現在、distutilsとsetuptoolsによって確立された規則以外に、 setup.cfgに関する標準はありません。 pyproject.tomlは、 setup.pyの後継として、ライブラリメタデータ用です。そうしないと、コミュニティは代わりにsetup.cfgにビルド要件を配置します。

pyproject.tomlは、プロジェクトの構築方法（PEP 518）を記述し、構築の一部はメタデータの記述です。 pyproject.tomlがこのメタデータの標準の場所を必要としていると言っているわけではありませんが、PEP 518はこのファイルを使用してビルドツールをインストールし、そこからビルドツールが別の場所からの宣言型構成を使用することを期待するのは非常に合理的ですプロジェクトのビルド方法を決定するためにファイル内で。

とにかく、pipenv vs poetryに戻ると、アプリケーションはエントリポイントなど、ライブラリが取得する特定の機能を必要としないという考えが浮かんでいるようですが、これは正しくありません。 アプリケーションがPythonパッケージであるのは簡単なはずです。

私のPythonや他のエコシステムでの経験におけるアプリケーションとライブラリの唯一の本当の違いは、ロックファイルを使用しているかどうかです。 もちろん、本当にrequirements.txtまたはPipfileで、実際のコードは必要ない3番目のケースがあります。これは、pipenvがこれまでに焦点を当ててきたすべてのようです（ pipenv install -e .が該当します） pipenvはまだパッケージのメタデータをサポートしようとすることを恐れているため、このカテゴリに分類されます）。 残念ながら、pipenvの設計はこのアプローチでよりクリーンになりますが、PEP 518がプロジェクトを編集可能モードにインストールする方法をパントすることを決定したため、ほとんどのアプリケーションではあまり役に立ちません。したがって、pipenvを使い続けるために、setuptoolsでかなり立ち往生します。 pyproject.tomlを使用してsetuptoolsから切り替えても、 pipenv install -e .使用することはできないため、長くなります。

現在、distutilsとsetuptoolsによって確立された規則以外に、setup.cfgに関する標準はありません。 pyproject.tomlは、setup.pyの後継として、またはコミュニティが代わりにsetup.cfgにビルド要件を配置するため、ライブラリメタデータ用です。

Distutilsは標準ライブラリの一部であり、setuptoolsは現在pipとともにインストールされているため、標準がないと言うのは少しばかげています。 言うまでもなく、メタデータなどにpep 345で概説されている標準を使用し、ビルド要件を指定するためにも使用できます。

コミュニティは、代わりにsetup.cfgにビルド要件を配置します。

あなたはpep作者を意味しますか？ あなたは彼らになぜ彼らが彼らの決定をしたのか尋ねることができます、彼らはそれをすべて大げさに概説します。

pyproject.tomlはプロジェクトのビルド方法（PEP 518）を記述し、ビルドの一部はメタデータを記述しています。 pyproject.tomlがこのメタデータの標準の場所を必要としていると言っているわけではありませんが、PEP 518はこのファイルを使用してビルドツールをインストールし、そこからビルドツールがファイル内の別の場所から宣言型構成を使用することを期待するのは非常に合理的ですプロジェクトの構築方法を決定します。

これは最近メーリングリストに登場しました-ビルドシステム要件を宣言するために使用されることを除いて、 pyproject.tomlの周りの標準を宣言しているところはどこにもありません。 それ以外はすべて前提です。 これを「ライブラリ定義メタデータ」と呼ぶことはできますが、そうではありません。 プロジェクトに関する追加情報を含まない（つまり、pep-345準拠のメタデータを含まない）ビルドシステムのみを定義し、それをpypiにアップロードして、その方法を教えてください。

とにかく、pipenv vs poetryに戻ると、アプリケーションはエントリポイントなど、ライブラリが取得する特定の機能を必要としないという考えが浮かんでいるようですが、これは正しくありません。 アプリケーションがPythonパッケージであるのは簡単なはずです。

アプリケーションはエントリポイントを必要としないと誰が言っていますか？ Pipenvには、これを処理するための全体的な構成があります。

したがって、pypenvを使い続けるためには、pyproject.tomlを使用してsetuptoolsから切り替えても、pipenv install -eを使用できないため、setuptoolsでかなり長くスタックします。

ここに従わない...バージョン10でpipベンダーを永久に残すつもりはありません、私は文字通り新しいリゾルバーについて説明しました、そして実際のインストーラーは単にpipに直接フォールバックします...これはどのように人々が編集可能なものを使用するのを防ぎますかインストールしますか？

これは最近メーリングリストに登場しました- pyproject.toml周りの標準を宣言しているところはどこにもありません

それは正しいです、それは「標準」ではありませんが、同じスレッドでそれをpyproject.tomlと呼ぶことによって、他のプロジェクト関連の設定/構成にこのファイルを使用するように人々に求めた可能性があることを認識しています。

したがって、ここで呼び出したのと同じロジックによって：

Distutilsは標準ライブラリの一部であり、setuptoolsは現在pipとともにインストールされているため、標準がないと言うのは少しばかげています。

pyproject.tomlは標準であり、コミュニティはビルドシステムやPythonプロジェクトの他の部分に関連する情報を配置するための標準的な場所としてそれを採用しています。

ここに従わない...バージョン10でpipベンダーを永久に残すつもりはありません、私は文字通り新しいリゾルバーについて説明しました、そして実際のインストーラーは単にpipに直接フォールバックします...これはどのように人々が編集可能なものを使用するのを防ぎますかインストールしますか？

PEP 517は編集可能なインストールでパントされました...つまり、セットアップツール（プロジェクトを編集可能なモードでインストールする開発モードと呼ばれる概念）を使用していない場合、プロジェクトを編集可能なモードでインストールする標準的な方法はありません。

Distutilsは標準ライブラリの一部であり、setuptoolsは現在pipとともにインストールされているため、標準がないと言うのは少しばかげています。 言うまでもなく、メタデータなどにpep 345で概説されている標準を使用し、ビルド要件を指定するためにも使用できます。

はい、ビルドシステムはPEP 345で説明されているPKG-INFOファイルを出力することが期待されています。これはsdistまたはwheelで送信され、setup.py / setup.cfgから生成される転送形式であり、代替ではありません。ユーザー向けのメタデータなど。 PEP 518のpyproject.tomlの使用法は、ビルドシステムとしてdistutils / setuptoolsの代替をサポートすることであり、現在、sdist / wheel形式を置き換えようとしている人は誰もいません。 これらの代替ビルドシステムには、メタデータを配置する場所が必要であり、幸い、PEP 517は、これらのシステムがそうするためにtool.名前空間を予約しました。 これは仮定ではありません。flitとpoetryの両方が、「ライブラリ定義メタデータ」にこの名前空間を採用しています。

プロジェクトに関する追加情報を含まない（つまり、pep-345準拠のメタデータを含まない）ビルドシステムのみを定義し、それをpypiにアップロードして、その方法を教えてください。

どのように建設的。

アプリケーションはエントリポイントを必要としないと誰が言っていますか？ Pipenvには、これを処理するための全体的な構成があります。

この構成はどこにありますか？ https://pipenv.readthedocs.io/en/latest/のpipenvドキュメントのどのページにも「entry」という単語が見つからないので、「構成全体」はかなりフェッチされているように聞こえますか？ 編集可能なインストールを意味する場合は、上記で作成したポイントに到達しました-予測可能な将来のpipenvのサポートのために、pipenvは、アプリケーションをパッケージとしてフックして開発する唯一の方法として、 pipenv install -e .に結合することを決定しましたここはsetuptoolsに結合されています。 論争全体は本当にこの時点まで要約されていると思います。人々（確かに私）は、setuptoolsを使用しないが、pipenvでそれらを開発できないライブラリを定義できるようになったことに不満を感じています。 完全に明確にするために、これは厳密にはpipenvのせいではありません（PEP 518は編集可能なインストールをパントすることを決定しました）が、詩がこの問題を準拠した方法で処理する代替手段を提供するため、問題を認めることを拒否することは談話でイライラしていますpyproject.toml形式で。 Pipenvは、詩は悪い決定を下すが、実際には前進する道を提供しようとはしないと言い続けています。

https://pipenv.readthedocs.io/en/latest/advanced/#custom -script-shortcuts

ドキュメントをお読みください。

@bertjwregeer ：

pyproject.tomlは標準であり、コミュニティはビルドシステムやPythonプロジェクトの他の部分に関連する情報を配置するための標準的な場所としてそれを採用しています。

すばらしいです。このシステムを使用して構築されたsdistsとwheelに対応できます。編集可能なインストールの標準が確立されるまで、pipを使用してsdistsとwheelを構築し、依存関係の解決をそのように処理し続けます。 私の回答を完全に読んでください。 pip、問題のpepsの作成者とメンテナ、そして私と@uranusjrは、編集可能なインストールの違いと、

私はすでにこれは正しくないと言いました。 あなたが実際に実装に興味を持っていて、生産的な会話をしているなら、私はそれを持ってうれしいです。 私たちが何をしているのかわからないと言っているだけで、私たちが何をしているのかを最初に学ぶことに興味がない場合、これが唯一の警告です。 私たちは限られた時間のボランティアであり、私は有毒な関与に対してゼロトレランスポリシーを実践しています。 私は自分の仕事が完璧だとは思いませんし、pipenvが完璧だとは思いません。 私はこの種の議論に私の時間と労力を喜んで貢献します。 引き換えに、彼らが敬意を払い、事実に固執し、参加する人々も喜んで私を学び、聞き、そして聞いてくれるようにお願いします。 ソープボックスだけにここにいる場合は、別のプラットフォームを見つける必要があります。 これは課題追跡システムです。 必要に応じてモデレートします。

この議論は非常にトピックから外れています。 誰かが目前の問題について建設的なことを言うことがあれば、遠慮なくその議論を続けてください。 ビルドシステムの実装について問題や質問がある場合は、新しい問題を開いてください。 ドキュメントに問題がある場合は、ドキュメントに関する多くのプルリクエストを受け付けており、作業が必要であることを認識しています。 その議論のすべてをそれらのトピックの新しい問題に延期

https://pipenv.readthedocs.io/en/latest/advanced/#custom -script-shortcuts
ドキュメントをお読みください。

エントリポイントは単なるコンソールスクリプトよりも一般的な概念であり、このリンクはこれらの懸念に対処する上で完全に誤りです。 <soapbox>禁止-ここで大規模なオープンソースプロジェクトを管理しているのはあなただけではありません。私のコメントは、あなたやプロジェクトに対する個人的な攻撃ではありません。 ここでコメントしている人々は、pipenvを使用し、それが行うことの多くを評価したいのでそうしています。 私のコメントは、このスレッドの最初のオフトピック投稿ではありませんでしたが、マークされたのはそれだけです。 私が何について話しているのかわからないとあなたが思うことを示すあなたの卑劣なコメントは恥ずかしくて有毒です。

私たちが維持しているプロジェクトでは、soapboxを使用できます。 はい、pipはすべての準拠ビルドシステムをサポートします。私が説明したように、pipenvはpipをバッキングツールとして使用してインストールプロセスを駆動するため、すべての準拠ビルドシステムをサポートします。ツーリング。 私はすでにこれを言いました。

そうそう、あなたの毒性をどこかに持っていってください。 あなたの態度はここでは歓迎されません。 最後通告。 対立を扇動するための永続的な試みは容認されません。