Pipenv: [質問] setup.pyと統合する方法は？

以下のコードでこれを達成できるはずです。 これにより、現在のプロジェクトからPipfileが読み込まれ、依存関係がpip互換リストに返されます。

from pipenv.project import Project
from pipenv.utils import convert_deps_to_pip

pfile = Project(chdir=False).parsed_pipfile
requirements = convert_deps_to_pip(pfile['packages'], r=False)
test_requirements = convert_deps_to_pip(pfile['dev-packages'], r=False)

ご不明な点がございましたら、お気軽にお問い合わせください:)

上記は非常に役立ちます。 setup.py install （または他の何か）を実行する前に、virtualenvにインストールされているPipenvに応じてsetup.pyで問題が発生しました。 私が考えることができるこの問題の唯一の解決策は、 from pipenv...をプロジェクトにベンダー化することですが、これは理想的とは言えないようです。違う。 誰かがこれよりもアイデアやより良い解決策を持っていますか？

Pythonコミュニティ（PyPAなど）の他の人に、将来のPythonリリースに正式に含まれるツールとしてPipenvを祝福するように〜嫌がらせ〜を提案する必要がありますか？ 😄

setup_requiresにpipenvを追加すると役に立ちますか？ install_requiresに追加する必要があるようですが、残念ながらそうです。

こんなことしないで。

@kennethreitz 「これ」とはどういう意味ですか？ setup.py、 @ nateprewittソリューション、または最後の2つの提案との統合を意味しますか？

では、ユーザーは、pipenvをインストールする必要があることをどのように知る必要がありますか？

pipenvは物事をインストールするために使用されるツールであり、その逆ではないため、setup.pyでそれを要求する理由はありません。 Kennethが警告しているのは、setup.pyにpipenvをインポートすることです。これは、CLIアプリケーションであり、問​​題を引き起こす可能性があるためです。

2017年10月17日午前9時37分、 IddanAhahronsonnotifications @ github.comは次のように書いています。

では、ユーザーは、pipenvをインストールする必要があることをどのように知る必要がありますか？

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信するか、GitHubで表示するか、スレッドをミュートしてください。

では、setup.pyで@ nateprewitt-のコードをどのように使用できますか？

@iddan ：Pipenvのバージョンをプロジェクトスケルトンにベンダー化するだけでPipenvブートストラップの問題を解決しようとしました（https://github.com/elgertam/cookiecutter-pypackage/blob/master/%7B%7Bcookiecutter.project_slug%7D ％7D / setup.py）。 setup.pyを使用してパッケージをインストールする状況でテストする機会がたくさんあったとは言えませんが、これまでのところ問題はありません。

setup.pyをロードするときにCLIを実行しないことが心配になる理由は理解できますが、私が知る限り、使用しているコード（ @nateprewittの投稿からコピーして貼り付けたもの）はかなり安全です。

pipにPipfile形式を理解するのに十分な内部構造がある場合、このハックは不要になると思います。

@iddan 、明確にするために、そのコードは、Pipfilesの依存関係をpipが読み取るrequirements.txtスタイルの形式に変換するためだけのものです。 ケネスが元の投稿から何かを編集したようですが、何がわかりません。

Pipenvは、setup.pyのような配布ではなく、環境管理およびデプロイメントツールとして意図されています。 Pipfileを使用していることを文書化し、インストール手順についてはpipenv.orgにリンクすることを強くお勧めします。 これをpipと同じように扱います。ユーザーが、新しいPythonパッケージをインストールするたびにpipをインストールすることは想定されていません。

私はそれを完全に理解しています。 私が理解していないのは、ユーザーがこのスクリプトを使用してパッケージをダウンロードし、pipenvがインストールされていない場合に何が起こると予想するかです。

@nateprewitt 、パッケージを配布する場合（通常の方法では、 pipを使用）、依存関係リストのコピーをsetup.pyまたはrequirements.txtに保持する必要があります？ 私は自分のPipfileを信頼できる唯一の情報源として使用したいと思っていました。

明確にするために、最初の応答のコードは、実際にsetup.pyで使用されるのではなく、ビルドの一部として実行されることを意図していると思います。

私がひどく誤解していない限り、 https： //github.com/kennethreitz/pipenv/issues/209#issuecomment -278185133のコードは、ホイール（= binary dist）を構築している場合は安全に使用できますが、そうでない場合は使用できません。あなたはsdist（= source dist）を構築しています。

ホイールの場合、 setup.pyはパッケージに含まれません（ただし、ビルド時に評価され、メタデータファイルは収集された情報に基づいて構築されます）。 ホイールを使用すると、パッケージがインストールされているマシンでsetup.pyが実行されることはなく、パッケージがビルドされた場所でのみ実行されます。

sdistでは、 setup.pyは実際にはインストールマシンで実行されるため、そこでpipenvを使用できる必要があります。

そうそう。 @tuukkamustonen 、私の特定のユースケースはsdistです。 pip installを実行する前にパッケージユーザーにpipenvをインストールするように要求したくないので、 setup.py install_requiresを取得することに固執していると思いますsetup.py （つまり、手動またはビルドの一部として）？

私が正しく読んでいれば、Kennethと他のメンテナは、 pytestの場合のように、 Pipenvをプロジェクトの依存関係として、あるいは通常のパッケージの依存関係として扱うことを望んでいないと思います。 理想的には、 pip自体と同じ方法でPipenvをインストールして更新する必要があるようです。つまり、Pythonのインストール時またはvirtualenvのときにpipがインストールされます。 virtualenvが作成されます。 それがケネスが「これをしないでください」と言ったときの意味です。

そうは言っても、 @ isobitは、 Pipfileが唯一の正しい情報源であるべきだという私の考えを反映しています。 Pipfileを支持するための2つの説得力のあるユースケースを見ることができます（他にもあります）。1つは、ビルド環境のセットアップをPipfileに依存するCI / CDパイプラインは、requirements.txtに依存するものよりもはるかに堅牢です。 次に、寄稿者がPipfileベースのプロジェクトをやみくもにインストールしようとすると、 python setup.py installが期待どおりに機能しない場合、イライラする可能性があります。 PipenvもPipfile対応のpipもまだ標準のPythonツールではなく、Pipenvが実際にPipfileのリファレンス実装であることを考えると、問題を解決するためのオプションはほとんどありません。

1）プロジェクトのドキュメントで、プロジェクトがPipenvに依存していることを指定します。 setup.pyでPipenvに依存することはできますが、Python環境にPipenvがインストールされていない場合、これは機能しなくなります。 具体的には、コードの寄稿者は、 setup.pyを使用してプロジェクトをインストールするために、 Pipenvを自分のvirtualenvに手動でインストールする必要があります。
2）setup.pyはrequirements.txtに依存します。これは、 Pipfileに基づいて定期的に生成します。 これはpipおよびsetuptoolsと完全に互換性がありますが、プロジェクトがビルドおよびデプロイされるたびに、メンテナがrequirements.txtを生成する必要があります。 これの可能なバリエーションは、CI / CDパイプラインがビルド時にrequirements.txtを更新することです。
3）Pipenvのバージョンをプロジェクトにベンダー化し、 setup.py from _vendor.pipenv.project import Project...を使用して呼び出します。 これの1つのバリエーションは、グローバルインポートが失敗した場合にのみ、ベンダーバージョンからインポートすることです。
4）ここに提示されておらず、私が考えるほど賢くない他のオプション。

Pipfileがより一般的な標準になるまで、私は個人的に（3）（https://github.com/kennethreitz/pipenv/issues/209#issuecomment-300550425を参照）を使用しています。 Pipenvは明らかにPipfileに基づいてvirtualenvを管理するためのツールであり、必ずしもPipfileライブラリ自体ではないため、Pipenvコードに直接依存します。

ここで読んだ内容に基づいて問題が明らかになることを願っていますが、間違った話をしたり、何かひどいことを言ったりした場合は、@ nateprewittまでお知らせください。

ここでの問題は、そもそもrequirements.txtの本来の誤用（IMO）に起因していると感じています。 それはpipenvの使用法からのアパートです。

Donald Stufftのこの素晴らしい記事、setup.pyとrequirements.txtを紹介します。
https://caremad.io/posts/2013/07/setup-vs-requirement/

TL; DR（ただし、実際に読む必要があります）： setup.pyのinstall_requiresは、パッケージの要件（依存関係）を詳しく説明するためのものです。 requirements.txt （ここではPipfile / Pipfile.lockコンボに置き換えられます）を使用して、必要なものを満たすために使用される正確なパッケージをリストします。再現可能な環境を作成するためのsetup.pyからのメタデータ。
requirements.txt install_requiresにデータを入力することは、逆方向に進むようなものです。

setup.pyのinstall_requires = / = requirements.txt （またはPipfile / Pipfile.lock ）。
Pipfile （またはPipfile.lock ）は、アプリの環境にインストールするパッケージの信頼できる唯一の情報源である必要があります。
setup.pyのinstall_requiresは、有効なPipfile.lockを生成するために使用されるメタデータを提供します。

そこから摩擦が生まれていると思います。 私はそれが理にかなっていることを願っています。

ヴィンセント、私はその返事がとても好きです、そして私はPipfile.lockがrequirements.txtの完全な（そしてより良い）代替品であることに絶対に同意します。

しかし、数か月間Pipenvを使用してきましたが、 Pipfileを使用すると、 install_requiresはPipfileとほぼ同じだと思います。 numpyが必要な場合は、 pipenv install numpyで、Pipfileの[packages]グループに新しいエントリが入ります： numpy = "*" 。 つまり、私の使用法は、 pip freeze > requirements.txtを使用してコミットする前に生成したばかりのrequirements.txtとはまったく異なります。

おそらく、これは私がPipenvを使用している独特の方法であり、私は穀物に反対しています（私は、プロジェクトディレクトリ内の.venv/にvirtualenvもインストールしているので、私は不正なPythonistaです）。ケース私はsetup.pyとPipfileの間に分離の壁があるというPythonコミュニティの慣習に簡単に準拠できます| Pipfile.lock | requirements.txt 。

@vphilippon、ここで何が欠けていますか？

情報をありがとう、@ vphilippon。 おそらく私たちはこれを逆行させているようですが、私たちが本当に望んでいるのは逆のようです-ドナルドが$の-e .に関して言及しているように、Pipfileでrequirements.txt install_requiresからの抽象depsを使用する方法ですrequirements.txt 。 それについてはすでに問題があったようですが（＃339）、どこにも行かなかったようです。

これはすでにPipfile構文でカバーされていますか？ リクエストライブラリPipfileがパッケージセクションで"e1839a8" = {path = ".", editable = true, extras=["socks"]}を使用していることに気づきました。 Pipfileの例でも同様のことが明らかですが、他のドキュメントはありません。

まず、免責事項：私の専門知識は主にlibパッケージに関するものです。 いくつかの点を見逃すかもしれません。 私は間違っている権利を持っており、それを使用する準備ができています！
また、これは私に私の頭を数回引っ掻くようにさせました。 これについてのレビューを本当にお願いします。

さて、これに取り掛かりましょう。

私はこのステートメント@elgertamから始めます：

[...] Pipfileの使用法から、install_requiresは実際にはPipfileにあるものとほとんど同じであると思います。 numpyが必要な場合は、numpyをpipenvインストールすると、Pipfileの[packages]グループに新しいエントリが入ります[...]

環境にnumpyを追加しましたが、アプリの依存関係にnumpyを追加しませんでした。
これらは2つの異なるものです。 読み続けてください、あなたは私が何を意味するかを見るでしょう。

言い換えると、私の使用法は、pipfreeze> requirements.txtを使用してコミットする前に生成したrequirements.txtとはまったく異なります。

驚いたことに、あなたがそれについて考えるならば、あなたの使用法はそれほど違いはありません：

• 以前のワーフロー： pip install stuff -> pip freeze > requirements.txt -> requirements.txt install_requiresをフィード
• 新しい（試行された）ワークフロー： pipenv install stuff -> Pipfileが自動的に更新されます-> install_requiresにPipfileをフィードしようとしています。
• 意図されたアイデアは何ですか： install_requiresに何かを追加-> pipenv install ->環境とPipfile.lockが更新されます。

そして、その意図された動作方法には、アプリをインストールすることを示すPipfileが必要です。
@isobitによってリンクされたrequests Pipfileのようなもの。

または、例：

[[source]]
url = "https://pypi.python.org/simple"
verify_ssl = true

[dev-packages]
pytest = ">=2.8.0"
tox = "*"

[packages]
"-e ." = "*"

Pipfileは、パッケージの依存関係ではなく、環境を説明するためのものです。 ご覧のとおり、上記のPipfileは、インストールするものを定義しています。これは、編集可能モードのローカルパッケージです。

これは少し「役に立たない」ように見えるかもしれません。現在、すべてが単一のパッケージによって駆動されているためですが、アプリをインストールしたいとしますが、 requests[security]を使用しますが、アプリからの厳密な依存関係ではありません。 pipenv install requests[security]を実行してから、次のようにします。

[[source]]
url = "https://pypi.python.org/simple"
verify_ssl = true

[dev-packages]
pytest = ">=2.8.0"
tox = "*"

[packages]
"-e ." = "*"
requests = { extras = ['security'] }

そして、これが抽象的な要件と具体的な要件の違いの例です。 gunicornやその他の環境に必要なものをインストールしたい場合も同様ですが、それはアプリ自体の一部ではありません。

@vphilippon、ここで何が欠けていますか？ Pipfileの[パッケージ]がinstall_requiresまたはtests_requireで使用するには制約が大きすぎるのはなぜですか？

私がこれを十分に説明したならば、あなたはそれがちょうど逆であることになっているのを見ることができます。
依存関係をinstall_requiresに入れ、パッケージをPipfileに入れてから、再現性のためにPipfile.lockを使用して環境を取得します（これにより、パッケージの依存関係）。

test_requireの場合、これがすべてに当てはまるかどうかはわかりません。 IIRC、そのsetuptools固有の機能。 これはテスト用の抽象的な依存関係のセットであり、すべてのパッケージに対してpipenvがそれらを解決してインストールし、 pipenv install --devを実行することを期待できますが、私はそれが正しくないと感じています。 申し訳ありませんが、これとその周りの論理的根拠について明確な考えや意見はありません。

これがどういうわけか理にかなっていることを願っています。

@vphilipponあなたはそれをかなりよく説明しました、そして私はあなたが私を納得させたと思います。

TL; DR： setup.pyに抽象的で絶対に必要な依存関係を指定し、 PipfileとPipfile.lockにコンテキスト（したがって具体性）を追加します。これには素晴らしい"-e ." = "*"も含まれます。

https://github.com/kennethreitz/pipenv/issues/209#issuecomment -337409290の問題は、アプリをサーバーにデプロイするときに、再現可能な環境が得られないことです。

つまり、通常、他のプロジェクトで使用される_library_を開発するときは、 install_requiresをかなり緩くする必要があります（=正確なバージョンへのバインドはありません）。 はい。 ただし、Webアプリ（または任意のアプリ）を構築してリモートサーバーまたはDockerコンテナーにデプロイする場合は、依存関係を修正する必要があります。 install_requiresで正確なバージョンを指定しても、推移的な依存関係はロックされず、インストールによって実際に別の（新しい）バージョンの推移的な依存関係がダウンロードされ、デプロイメントが破損する可能性があります。

（推移的な依存関係の正確なバージョンを手動で宣言することはオプションではありません-非常に面倒です。）

このユースケースでは、 requirements.txtスタイルのロックファイル（推移的な依存関係に対しても正確なバージョンを指定する）に依存する必要があります。 ただし、pipenvがpipenv lock -r （たとえば、 pipenv lock --no-dev -r ）の開発要件を除外できるようには見えないため、実際にそのようなrequirements.txtを作成できます（ install_requiresに読みます）？

DonaldStufftの記事を引用します。

アプリケーションには通常、一連の依存関係があり、多くの場合、非常に複雑な一連の依存関係がテストされています。 デプロイされた特定のインスタンスであるため、通常、名前も、他のパッケージ関連のメタデータもありません。 これは、pip要件ファイルの機能に反映されます。

言い換えれば、アプリはパッケージではありません。 アプリは、一連の具体的な依存関係がインストールされた環境です。 アプリの依存関係は、単一のパッケージinstall_requiresではなく、 requirements.txt （またはPipfile / Pipfile.lock ）で表す必要があります。

個人的には、固定された依存関係の完全なセット（推移的な依存関係を含む）は、パッケージのsetup.pyではなく、アプリのrequirements.txtに含まれている必要があります。 これは、アプリのデプロイがpip install myapp==1.0.0ではなく、 pip install -r requirements.txt （または$＃ Pipfile.lockの場合pipenv install $）で行われるという考え方の概要です。ここで、 requirements.txtには、 myapp==1.0.0と、固定された他のすべての依存関係および推移的な依存関係が含まれます。
少し先に進んでいるように見えるかもしれませんが、デプロイされた「アプリ」が一連のパッケージによって駆動されるコンテキストで作業しました。 アプリ自体を表す単一のパッケージはないので、「パッケージはアプリではない」というこの概念は、かなり早い段階で私の顔に投げかけられました😄。

Pipenv / Pipefile /Pipfile.lockがこの考えに従っていると強く感じています。
そのため、 Pipfile.lockからsetup.pyのinstall_requiresに移行するためのギャップがあるように思われます。いずれにせよ、実際にはそのように行われることを意図したものではありません。

@maintainersここでの入力で、これが実際にこれらすべてをどのように見ているかを知りたいと思います。 私は依存関係をどのように扱うべきかというビジョンを説教してきましたが、あなたの代わりに話したいとも思いません。

@vphilipponさまざまな視点や用語があると思います。 しかし、最終的には、固定された依存関係のリストをインストールする必要があります。 したがって、固定されたバージョンのrequirements.txt （またはそのような宣言された依存関係を持つパッケージは実際には重要ではありません）。 問題は、そのようなファイルを実際にどのように作成するかということです。

（ pip-toolsの） pip-compileを使用すると、そのようなrequirements.txtをrequirements.in $からコンパイルでき、アプリに必要な非開発依存関係のみが含まれます。 あなたの応答を正しく解釈しているかどうかはわかりません-固定された依存関係を手作業で維持する必要があるということですか（ requirements.txt setup.pyにすでにあるものをわずかに複製することもできます）。推移的な依存関係？ それは解決策にはなりえません...

pipenv lock --no-dev -rがあれば、この問題は解決すると思います。

@tuukkamustonen混乱して申し訳ありませんが、私は実際にはinstall_requiresとrequirements.txt / Pipfile / Pipfile.lockのアイデアだけを取り上げていました。

したがって、固定されたバージョンを含むrequirements.txt（またはそのような宣言された依存関係を持つパッケージは実際には重要ではありません）。

区別は非常に重要だと思いますが、おっしゃるように、ここにはさまざまな視点があります。 今のところ同意しないことに同意しましょう。 ちなみに、特定の問題にノイズを追加することなく、主題を継続するための場所があると便利です。 それは、コミュニティ、IMOでより多くの議論と共有が必要な種類のものです。

ただし、pipenvがpipenv lock-rの開発要件を除外できるようには見えません。

しかし、最終的には、固定された依存関係のリストをインストールする必要があります。 [...]問題は、実際にそのようなファイルを作成する方法です。 [...]（pip-toolsの）pip-compileを使用すると、requirements.inからそのようなrequirements.txtをコンパイルでき、アプリに必要な非開発依存関係のみが含まれます。

ああ、最初はその部分をスキップしました、ごめんなさい。 そして、あなたは正しいようです。 pipenv install --not-dev-stuffと言う方法を見つけることができず（奇妙なことですが、確かに1つあると確信していました）、非開発環境を生成します。 では、2つの別々のセクションを持つことのポイントは何ですか？ 私は今何かが足りないかもしれません、そしてそれはsetup.pyでの使用法とは無関係です。 たぶん、新しい問題で議論する価値があります。

編集：
ここで間違えました。 私は確かに開発パッケージなしでPipfile.lockを生成する方法を見つけませんでしたが、新しい環境では、既存のPipfile / Pipfile.lockを使用して、 pipenv install実行しますdevパッケージはインストールされません。 これは@tuukkamustonenのポイントを解決しませんが、「本番環境」をインストールする方法がないと言ったとき、私は間違っていました。私の間違いです。

ふぅ、それは追いつくことがたくさんありました。

私がひどく誤解しない限り、＃209（コメント）のコードは、ホイール（= binary dist）を構築している場合は安全に使用できますが、sdist（= source dist）を構築している場合は使用できません。

@tuukkamustonenこれは、デプロイメント用のスタンドアロンスクリプトでのみ使用することを目的としており、setup.pyには含めないでください。 これは、何ヶ月も前にpipenv lock -rを入手する前からのセミハッキーな回避策です。 ただし、このアプローチは、 packagesとdev-packagesを分割するユースケースで機能します。

Pipfileがより一般的な標準になるまで、私は個人的に（3）（＃209（コメント）を参照）を使用しています。 Pipfileに基づいてvirtualenvを管理するためのツールであり、必ずしもPipfileライブラリ自体である必要はありません。

@elgertamこのコメント以降、あなたの意見は揺らいでいるようですが、プロジェクトにpipenvをバンドルするのはおそらく良い考えではないことに注意してください。 これを明示的に禁止するものはありませんが、このように使用すると問題が発生しやすいパスパッチを多数実行します。 これを「自己責任で使用してください」という警告でラップするだけだと思います。

メンテナここでのあなたの意見に、これが実際にあなたがこれらすべてをどのように見ているかを知ってもらいたいと思います。 私は依存関係をどのように扱うべきかというビジョンを説教してきましたが、あなたの代わりに話したいとも思いません。

あなたは、プロジェクト期間中の私たちのビジョンとかなり一致していると思います。 これをすべてコンパイルしてくれてありがとう@vphilippon！

この議論の他の関連部分は＃942に移されたように見えるので、私たちはここで良いと思います。 何も対処しなかった場合は、pingを送信してください。

私はhttps://github.com/pypa/pipfile/issues/98で具体的な提案をフォローアップしました。これは、Pythonライブラリを維持するためのDXを改善できる実用的で実用的なものを提供すると信じています。

考え？

import json, jmespath

install_requires = []
with open('Pipfile.lock') as f:
    context = json.loads(f.read())
    install_requires.extend(map(
        lambda n, v : n + v,
        jmespath.search('default | keys(@)', context),
        jmespath.search('default.*.version', context),
    ))

setup(
    name='foobar',
    packages=find_packages(),
    setup_requires=['jmespath'],
    install_requires=install_requires,
)

@cornfeedhobo私の理解では、setup_requiresはpipではうまく機能しません。 このサンプルの使用方法について少し詳しく教えてください。

setup.pyは通常のPythonコードとして評価されるため、最初にjmespathをインストールしない限り、サンプルは機能しません。 setup_requires引数は、実際には何も達成しません。プログラムがそこまで到達した場合、jmespathがインストールされることが保証されます。

これについては別の号で触れましたが、atmを見つけることができません（課題トラッカー全体で重複したディスカッションが非常に多く、もう何も見つけることができません）。もう一度言います。構築されていないものは入れないでください-適切なフォールバックを提供するか、完全な理由がない限り、setup.py内にあります。 上記のsetup.pyを含むパッケージは、virtualenvにjmespathがインストールされているPipenvでも機能しません。 Pipenvは、クリーンな環境でsetup.py egg_infoを呼び出し、jmespathインポートの実行に失敗します。 これは悪い習慣です。 避けてください。

@epot私はそれを知りませんでした

@uranusjrよく考えられた答えと詳細をありがとう。 私はこの問題全体を調査しているだけなので、もっと恥ずかしい思いをするかもしれません。 pypa / pipfile＃98も追跡しています

jmespathが必要ない場合はどうなりますか？

import json


install_requires = []
tests_require = []

with open('Pipfile.lock') as fd:
    lock_data = json.load(fd)
    install_requires = [
        package_name + package_data['version']
        for package_name, package_data in lock_data['default'].items()
    ]
    tests_require = [
        package_name + package_data['version']
        for package_name, package_data in lock_data['develop'].items()
    ]

@mschwagerバージョンを固定したくない場合、ユーザーは困難な時間を過ごすことになります。 ＃1921は、 ==を使用するライブラリの例であり、ユーザーのビルドを壊してしまいます。

申し訳ありませんが、パッケージとして使用するためにsetup.pyを使用する場合と、そのパッケージの依存関係を管理するためにrequirements.txt / Pipfileを使用する場合の違いは何ですか？ 必要なライブラリは、 setup.pyとrequirements.txt / Pipfileの間で同一である必要がありますか？ したがって、 Pipfileを統合しない理由はありません。 setup.pyすでにrequirements.txtを解析しています。 Pipfileを解析できないのはなぜですか？

requirements.txt Pipfileを使用するのは素晴らしいことです

いいえ、それらが同一である必要がある理由はありません。 それは非常に過激な仮定であり、コミュニティの多くは違いを懇願するでしょう。

ただし、実際には、それらが同一である可能性がある理由があります。 Pipenvはそれを除外していません。 これは範囲外であり、このプロジェクトではサポートされていません。 これをサポートするライブラリを完全にビルドし、pip10.0に組み込まれているPEP518を活用して、ビルド時のサポートを提供できます。

あなたが言ったように、setup.pyがPipfileを解析することを許可しない理由はありません。 私はあなたがそれを実現するのを楽しみにしています:)

setup.pyの抽象ライブラリが好きな人もいますが、それは必須ではありません。 つまり、golangには具体的な要件しかないのに、名前と一致しているという理由だけで、必要なlibを独自のフォークに置き換えることができるということですか？ setup.pyのインターゲーションがスコープに含まれていないことは理解できます。

ただし、pipenvの長期ロードマップが何であるかを確認するのは興味深いでしょう。 それがPythonのgotoツールになるのを見るのは素晴らしいことです。 たとえば、どういうわけかsetup.pyを置き換えるか、ユーザーに適切なsetup.pyを生成します。いずれにしても、pipenvが事実上のパッケージマネージャーであることは素晴らしいことです。 setup.pyを含むようにスコープを拡張する可能性があるかどうか疑問に思っていますか？

pipenvがnpmなどのようなものである場合、それらのpackage.jsonはリモートインストールを許可します。pipenvがsetup.pyと対話したり、setup.pyを置き換えたりすることができない理由はなく、スコープ内にあります。 私は理にかなっていますか、それとも私が狂った薬を飲んでいるように聞こえますか？

必需品だと思っていただきありがとうございます。 それが非常に重要であるとあなたが考えているので、私たちはすぐにPipfileベースのビルドシステムを実行できると信じています。