野心的な提案！

ini構成のサポート（ユーザーのホームに存在するグローバルini構成）

appdir（または同様のもの）を使用して、プラットフォームが推奨する場所の構成を検出することを検討してください。

appdirsはオプションである可能性がありますが、その場合は、パッケージにデータをベンダーするビジネスを開始する必要があります。 公平を期すために、これの70％はすでに行われているので、より良い再編成が必要です。

単にそれに依存するのではなく、なぜベンダーなのか？ （ベンダーに提供するのは難しいことではありません。単一のファイルです）。 IMO、私たちは本当に（pipを除いて）パッケージングツールが他のアプリケーションと同じように構築されるべきであることを受け入れる必要があります。 依存関係を持つことがPyPAアプリがそれらを回避するのに十分難しい場合、それは、ユーザーがアプリケーションを開発しやすくするために私たちがどれだけうまくやっているかについて何を言いますか？

（申し訳ありませんが、ここではvirtualenvについてなんらかの大きなポイントを述べていません。「PyPI依存関係を追加することは大したことではない」と言う人が非常に多いので、ベンダー向けに使用しているPyPAツールに疑問を抱きます...） 。

クロスインタープリター機能をベンダー化しないと、難しいと思います。 たとえば、virtualenvがインストールされていないインタプリタ用の仮想環境を作成します。

PYTHONPATH = / t / path / to / virtualenv.whl python -m virtualenv

ええと、これは、virtualenvからの追加のパッケージに依存できないことを意味します。 zipappを提供するので、これによりどのようなユースケースが可能になりますか？

@gaborbernat -pオプションのことですか？ たぶんそうだ。 まさにzipappsが支援することを意図したような状況のように思えますが、それをうまく機能させるための詳細を打ち砕くために実際に多くのことをした人は誰もいません。

@pradyunsgから：

ええと、これは、virtualenvからの追加のパッケージに依存できないことを意味します

実際、 @ gaborbernatが言ったように、 -pオプションはおそらく次のことを意味します:-(しかし、なぜ「wheel on PYTHONPATH 」オプションとzipappが必要なのか疑問に思います-特にそのホイールを考えるとPYTHONPATHは一般的にサポートされていません（通常のpipブートストラップの理由により、virtualenv内で内部的に使用します-pipはほとんどすべての例外です;-)）

2年間のサポート

うーん...

ここでの私の心配は、これによるネットワーク効果により、新しいバージョンのPythonの採用が遅くなり、サポートされているPythonの数が急増する可能性があることです。 CPythonは3.9のさまざまなリリースのリズムについて話し合っているため、2年は、一部のリリースがコア開発者からのものよりも長くなる可能性があります。

そうは言っても、私はこれをブロックしたくはありませんが、ほとんどの場合、これを実行することに熱心ではないことを声に出して確認します。

（ある時点でIronPythonとJythonを期待しています-他にサポートすべきものはありますか？）

間違いなく。 @gaborbernatはおそらく私がこれを言うことを知っています-これらは持っていれば良いでしょうが、実装に精通している人々はこれを行うのに最適な立場にあると確信しています。 少なくとも、長期的なサポートの観点から、そして理想的には、そもそもそれを十分にサポートするための作業（CI、テストなど）。

まず、ini構成のサポート（ユーザーのホームに存在するグローバルini構成）、

私は偏見があります-代わりにこれをTOMLにしたいと思っています。 :)

（私はどこかに行かなければならないので、これをまだ完全に処理していません-しかし、これは素晴らしい全体的な目標のように見えます！）

クロスインタープリター機能のため、すでに追加のパッケージに依存することはできません。したがって、これを大きな欠点とは考えていません。仮想環境を実行するための単純なインストール/依存のない方法が必要です（人々が必要とする場合）ノードパッケージから呼び出します）。 それが私たちに多くの提供を要しないことを考えると、zipappは安いようです。

組み込みのvenvを優先する：ターゲットPythonにvenvがある場合は、それを使用して環境を作成します（その後、それに対して後続の操作を実行して、提供する他の保証を容易にします）

この理由がよくわかりません。 それはのメンテナンスになりますように思えるvirtualenv困難を、エンドユーザーが理解することは、行動が難しくなります。 setuptoolsは、モンキーパッチを継続するのではなく、 distutilsを吸収しようとすることで、すでに逆の方向に進んでいます。

@pganssleスコープは異なり、問題のあるスペースも異なります。 virtualenv問題は、多くの場合、システムがシステムパッケージに追加の制約を課すため、これらに準拠するように組み込みのvenvにモンキーパッチを適用することです。 これらすべてを複製するのは難しいでしょう。例えば＃1362を参照してください。

FWIW組み込みのvenvパッケージを分離に使用するのは正しい考えだと思います。これは、実際のインタープリターに組み込まれているため（stdlibモジュールであるdistutilsではなく）、 virtualenvよりもはるかにクリーンな処理を実行できます。

Virtualenvもモンキーパッチを適用する必要はなく、パブリックAPIを使用するだけで問題ありません。

FWIW古いrewritevirtualenvブランチをチェックすることをお勧めします、それはすでにこれらの多くのことをしました。

プラグインシステムはvirtualenvにはあまり役に立たないことをお勧めしますが、せいぜい1つのフック、作成後のステップがあり、それでもインストールするもののリストを持っているだけで済ますことができます。

また、「自然に」ものに依存し、zipappsを使用することもできます。必要なのは、zipapp自体の内部でベンダーを作成することだけです。 ターゲットpythonオプションの下での再実行から離れることをお勧めします。これは悪いことであり、はるかにクリーンに実行できます。

697- @ dstufftの古いPR

PYTHONPATH = / t / path / to / virtualenv.whl python -m virtualenv

OTOH、我々はおそらく、とにかくこれを実行すべきではない- https://www.python.org/dev/peps/pep-0427/#is -it-可能・ツー・輸入のpython-コードを直接-from- a-wheel-file

@pradyunsgでは、ホイールをパスに配置せずにピップをブートストラップする他の方法はありますか？

ブートストラップpipはおそらくOKです-これはvirtualenvが現在使用しているものです¹ 。 ただし、virtualenv自体を実行する手段としてではなく、pipにのみ使用することを強くお勧めします。

¹しかし、複雑な機能は避けたいと思います。PATHでホイールを使用して、そのホイールからpipをインストールすることで、問題がないことがほぼ保証されます。 しかし、たとえば、certifiには実際のファイルとして埋め込まれた証明書バンドルが必要だと思うので、このようなホイールを使用してインターネットにアクセスすると、問題が発生する可能性があります（ただし、間違っている可能性があります。問題が発生することはありませんが、 get-pip.pyを知っています。

pipをzipappとして出荷しない理由は何ですか？ 私が理解しているように、それはこの必要性を回避するでしょう、そしてzipappはpython2.7でサポートされています🤔

@gaborbernat試してみましたか？ それは機能しますか？ 概説したアプローチがWindowsで機能する場合、最初の懸念はありませんが、 @ uranusjrからフィードバックが@dstuffと

pipをzipappとして出荷しない理由は何ですか？

上で述べたように、場合によっては、pipがzipファイル（またはホイール、同じこと）から直接実行されないことがあります。 99％（アラート-構成された数）は機能しますが、証明書バンドルが実際のファイルである必要があるという事実が重要になる場合があります。

ただし、shivは実行前にzipappを解凍するため、zipからの実行が中断するコーナーケースを回避するために、pipをshivとしてバンドルすることはおそらく問題なく

いつものように、それが起こらなかった主な理由は次のとおりです。

1. 誰もそれについて考えませんでした。
2. 誰もそれをする時間/動機を持っていませんでした。
3. 現在のアプローチはうまく機能しており、揚げる魚はもっと大きいです。

それで、車輪をパスに置かずにピップをブートストラップする他の方法はありますか？

ここでは必要ないと思います。virtualenvはピップホイールを使用してIIRCをインストールしていますが、これは正常に機能するはずです。 @pfmooreが言ったように、

現在のアプローチはうまく機能しており、揚げる魚はもっと大きいです。

これは、他のIMOよりもはるかに多いです。 可能ですが、取り組むべきより影響力のある問題があります。 :)

ある時点で、zipアプリとしてpipを構築するPRがありましたが、それは機能しましたが、IIRCを完全に機能させるには、pipに変更を加える必要がありました。

pipはPEP517のサブプロセスとしてそれ自体を呼び出すため、これは少し複雑になる可能性があります。よくわかりませんが、調査する価値はあります。

この時点で、shiv（または別の自己解凍オプション）は、pipをzip形式で実行しようとするよりもpipに適しています。 しかし、現時点ではこれは特に重要なことではないと思います。 surepipはすでにホイールオンパスルートを進んでいます。同じことをしてみませんか。 すべての大きな魚を揚げた後、代替のピップブートストラップを検討することができ、stdlibに戻る可能性があります。

すべての大きな魚を揚げた後、代替のピップブートストラップを検討することができます

計画のように聞こえます[私たちがすでにフォローしている計画です。 ;）]

リンクをありがとう、フィードバックに基づいて、 https：//github.com/gaborbernat/virtualenv/tree/rewrite/src/virtualenvで最初の作業を開始しました20.0.0リリースする予定です。

存在する場合、venvを使用するための+1。 これにより、PyPyのユースケースが簡単になります。

それで、書き直しは、人々がそれを見て、いくつかのフィードバックを与えることを快適に感じる状態になりました。 これを手伝うための自由な時間があれば、私に連絡してください。 計画は月末までにリリースされる予定です🤞注https://github.com/pypa/virtualenv/milestone/7はまだ実装する必要がありますが、コアアイデアはそこにあります。

PS。 https://github.com/pypa/virtualenv/pull/1481/の下にフィードバックPRを作成しました

機能のリクエスト：たとえば、 env.txtファイルをvenv binディレクトリに標準形式で配置することにより、カスタム環境変数を定義するためのメカニズムを提供します。

VARNAME=value
OTHERVAR=othervalue

私はあなたのユースケースを理解していないと思いますか？ これらの環境変数はいつどのように使用、設定されますか？

編集。 NM。 https://github.com/pypa/virtualenv/issues/1124で展開されているようです

小さな更新。 私は、まだ愛情が必要な2つを除いて、ほとんどのブロッキングの問題を解決することができました。テストには、ヘッダーと、アプリデータに適用されたロックを使用したPython問い合わせ呼び出しのキャッシュが含まれるため、仮想環境を並行して（さまざまな場所に）作成できます。 現在のペースでは、私は数日遅れるかもしれません...しかし、間違いなく2月7日までに外出するはずです。

ロールアウトの観点から、私たちの計画は何ですか？ メインリリースの前にベータ版をリリースしますか？

ええ、月曜日に何かを出したいです...そして、フィードバック、修正のために暫定的に1週間残します...そして、マスターをリライトとリリースに置き換えます。

1週間で十分かどうかは100％確信できません。ベータ版を試してもらいたいということを、複数のチャネルで確実に伝える必要があります。

暫定的にあったキーワード。 私はここで楽観的です。私が費やした努力の量を考えると、大きな問題は予想していませんが、🤷‍♂

virtualenv 20.0.0beta1が利用可能です。

ベータ版がリリースされているので、この問題が解決されたことが目的だと思います。 最後に、専用の問題に焦点を当てて話し合うことができます。