Pipenv: 可能な場合は、virtualenvの代わりにvenvを使用します

私はそうは思いません、私はvirtualenvコマンドを個人的に使用することを好みます

たぶん、両方のオプションを共存させることは可能ですか？ ソースをさりげなく閲覧していると、envの作成に使用されたコマンドを除いて、Virtualenvと特に関連しているものは何も表示されません。 VIRTUALENVは常にデフォルトとすることができるが、ユーザは、（例えば）を渡すことができる--venv作成する.venv用いてpython3 -m venvの代わりにvirtualenv 。

私は正直に言って、pipenvだけに依存していて、virtualenvとvenvのどちらが使用されているかは気にしませんが、利用可能な場合は組み込みを活用できると考えました。

@kennethreitzに、ここで彼のコメントを再検討することをお勧めします。 virtualenvの代わりにpython3 Python3のみを使用してvenvのみを使用して

@bulletmark PipenvがほとんどすべてのVirtualenv管理をPewに委任するようになったため、切り替えるのはさらに困難ですが、Pewがvenv （berdario / pew＃67）をサポートする計画があるため、まだチャンスがあります。 Pewがそれを機能させることができれば、Pipenvでvenvサポートを実装する方がはるかに簡単です（そして少なくとも私にはもっと理にかなっています）。

@uranusjrは素晴らしいですね！

私は個人的にvenv使ったことがないので、それに対する不安があります。 でも、それは良いことだと確信しています。

今、物事はうまくいっています。 壊れていないものを変更する必要はありません。

システムが壊れているため、最終的にこのスレッドを見つけました。

Python 3.Xでvirtualenvを使用して環境を作成し、Python 3.Yにアップグレードすると、Pythonが必要とする共有ライブラリがなくなったことがわかっているため、virtualenvが壊れます。 venvを使用すると、 python3 -m venv --upgrade実行できます。

これは素晴らしい機能です。

これは間違いなく素晴らしいことであり、Pythonの方向性と一致していると感じます

venvを使用しない（代わりにvirtualenvを使用する）ことは、私にとって完全なショートッパーです-私はPipenvを使用できません。 私はvirtualenvを使用できません。これは、Pythonバイナリをコピーするという苛立たしい振る舞いのためですが、共有ライブラリに依存しています。 これは常にvirtualenvsを壊し（システムpythonが更新され、バイナリがぶら下がっているときはいつでも）、不必要にpythonバイナリをコピーしますがまったくメリットはありません。

pipenvがPythonの将来である場合、デフォルトでPython 3でvenvを使用する必要があります（使用しない場合は警告します）。 Python 3に組み込まれており、推奨されるツールです。 Pipenvも現在推奨されているツールですが、venvを使用していないのは非常に奇妙です。

Python自体の一部であるvenvは、Python自体の内部にアクセスできるため、ハッキングを大幅に減らして正しい方法で処理を実行できます。 たとえば、virtualenvはPythonインタープリターバイナリを仮想環境にコピーして、分離されていると思わせる必要がありますが、venvは、Pythonバイナリによって通常の場所で読み取られる構成ファイルを使用して、動作するはずであることを認識できます。仮想環境のように。 したがって、venvは、Python開発者の祝福とサポートを受けて、正しく実行されたvirtualenvと考えることができます。

ソース： https ：

私はberdario / pew＃173を始めましたが、進歩する時間があまりありませんでした。 上記のように、Pewがサポートすると、Pipenvはこれを自動的にサポートします。 誰かがvenvをPipenvに持ち込むことに興味があるなら、私はいくつかの助けが欲しいです。 現在の主な問題は、テストに合格することです。

venvサポートのクイックアップデート：少なくとも近い将来、それは起こりません。 venvは、これを実現するのに十分ではありません。 これが本当に気になる場合は、 Pythonバグトラッカーにアクセスして手を貸してください。 それ以外の場合は、 virtualenvに固執します。

venvはPythonに推奨されるツールであり、virtualenvのように壊れることはありません（再：pythonバイナリをコピーすると、python libsが更新されると壊れます）。 あなたがリンクしたバグは、venvとvirtualenvの組み合わせに関するものですが、これは私たちが求めているものではありませんか？

残念ながら、ツールがvirtualenv上に構築されることは非常に一般的です。 たとえば、Travisは、元のレポーターが述べたように、virtualenvを使用してビルド環境を作成します。 これはPipsiの基盤でもあり、Pipenvをインストールするための推奨される方法の1つです。 venvがその中でうまく機能しない場合。 知らないうちに色んな所にあります。 Venvのサポートは半分壊れており、virtualenvでうまく機能しない場合は、予期しない方法であなたを噛みます。

私はそれを理解していますが、現時点ではPipenvが推奨され、venvが推奨されており、それらはある種競合しています。 その非常に奇妙な状態。

私はそれが奇妙な状態にあることに完全に同意します、それが私がそれを修正しようとしている理由です:)私はそれが修正されないと言っているわけではありませんが、最初にアップストリームの変更を行う必要があり、彼らまで私ができることは何もありません起こる。 リンクを投稿するのは、作業をやめる言い訳ではなく、この状況を改善するために最初に努力する場所を人々に知らせるためです。

たぶん、この問題を開いたままにしておくのはそれほどクレイジーではないでしょうか？

これはピューの問題であり、pipenvの問題ではありません。

venvは、これを実現するのに十分ではありません。 これが本当に気になる場合は、 Pythonバグトラッカーにアクセスして手を貸してください。

これはvenvの問題ではなく、virtualenvの問題です。 課題追跡システムの下に説明を投稿しました。
cc @uranusjr

周りに言葉があります->
venvを使用して最初にvirtualenvを作成してから、 pipenv installます。 例えば：

mkdir -p /tmp/try
cd /tmp/try
python3 -m venv .venv
pipenv --venv  # /tmp/try/.venv
pipenv install xxx

🙈

注：

上記の回避策はほとんど機能しますが、 activate_this.py下に.venv/bin activate_this.pyがないため、 pipenv run ...失敗します。 問題21496を信じる場合、このファイルをvenvに追加する予定はありません。 したがって、pewがこれを修正したとしても、pipenvにはまだ問題がある可能性があります。

virtualenvを使用して、macOSでsystemtkモジュールを使用することは不可能です。 しかし、venvを使用すると、それは可能です。
私はpipenvでvenvを強く使いたいです（オプションかもしれません）。

参照：＃1416

冷笑的に聞こえるわけではありませんが、本当に気にかけているのであれば、これをサポートするコードを実際に誰かに書いてもらいたいと思います。 これについて「強く」感じていると言う人にたくさん会いましたが、私が知る限り、実際に何かをするのは私だけです。 そして私は失敗しました。 これはあなたが思うほど単純ではありません。 あなたがもっとうまくやれると思うなら、何かをしてください。 したくない場合は、手に入るものを持っていってください。

（kennethと私、そしておそらくerinとnateも、プロジェクトのかなり早い段階でvenvを使用してこれを実行しようとしましたが、互換性の理由で失敗しました）

これはいいことだ、誰もが同意する。 プラットフォームやPythonバージョン間で機能することを望んでいます。

venvがvirtualenvよりもおそらく良い選択である他の理由を指摘したいと思います。

virtualenvの実装の醜い側面の1つは、サイトモジュールの独自のコピーが必要なことです。これは、Pythonのバージョンに関係なく、すべてのvirtualenvで使用されます。
--https ： //github.com/pypa/virtualenv/issues/228#issuecomment-4165148から

これは、たとえば、 rlcompleterがデフォルトで無効になっていることを意味し、これは私の意見では大きなユーザビリティの損失です。

さらに、これは複数のユーザーに影響を与える問題であるため、アップストリームで変更が行われるのを待っている場合でも、問題が修正されるまで開いたままにしておくことをお勧めします。

また。 私たちはそれがより良いことを知っています。 それは実際には不可能です。 何がより悪い影響を及ぼし、大部分のユーザーの機能を完全に破壊したり、一部のユーザーにリードライン機能をオンにしなければならないと思いますか？

これは不便だと思います。また、これを要求している人がいるように見えても、機能する実装を提供する人がいないことも不便です。 やってみました。 何かが大幅に変更されるまで、venvをサポートする予定はないため、この問題を開く予定はありません。

@techalchemy私が正しく理解していれば、pypa / virtualenv＃1095はこれを議論する正しい場所ですか？

正しいようですが、toxには回避策があるので、誰かがそれを移植した場合はうまくいくかもしれません

ピュー！ どのような議論がありますか..このピューなものがそれほど重要ではない場合、virtualenvと一緒にそれらを完全に削除し、pipenv、venv、およびpythonを相互に推奨するので、それらを連携させることは可能でしょうか？

Pythonの依存関係管理/仮想環境ソリューションは、今のところあまりにも荒れた地形であり、いくつかの犠牲を払う必要があります。

これは、virtualenvの使用をやめる準備がまだできていない多くの人々を怖がらせる可能性がありますが、今後のメジャーリリースの1つで計画される可能性があります（技術的に実現可能であれば）。変更は避けられません。時間の問題です。

@doganmeh virtualenvを完全に放棄して、Python 3.3以降のみをサポートする同等の製品を構築することもできますが、別のプロジェクトを作成する方が簡単だと思います。

注：

上記の回避策はほとんど機能しますが、 activate_this.py下に.venv/bin activate_this.pyがないため、 pipenv run ...失敗します。 問題21496を信じる場合、このファイルをvenvに追加する予定はありません。 したがって、pewがこれを修正したとしても、pipenvにはまだ問題がある可能性があります。

それは本当に必要ですか？ venvを使用して仮想環境を作成したら、それを使用するためにアクティブ化する必要はありません。 venv / binディレクトリからpythonバイナリを使用して実行するだけです。

FWIW、これは関連しています（そして私をここに連れてきたもの）： http ：

virtualenvでは、環境がフレームワークビルドから作成されている場合でも、非フレームワークビルドが使用されます（ virtualenvバグ＃54 、 virtualenvバグ＃609 ）。

解決策は、virtualenvを使用せず、代わりにstdlibのvenvを使用することです。これは、同様の機能を提供しますが、この問題は発生しません。

Python 2.7 / virtualenvのサポートを私にドロップすることは、サポートが間もなく期限切れにならないPythonバージョンのstdlibにpipenvが依存することを許可する場合、特にひどい考えのようには聞こえません。 メンテナが簡単に修正できないpipenvツールチェーンの他の部分が破損しない限り。 たぶん2.7サポートを別のブランチ/パッケージに移動することさえできますか？

実際のコードを提供できるようにしたいと思いますが、そうするために必要な経験や時間はないと思います：frown：私ができる最善のことは、現時点でディスカッションに追加することです。

ここに私の声を追加します。 @dmtuckerと同じ問題があるため、これをヒットし

私は現在、Mac上でこのプロジェクトのためにpipenvを完全に無視し、今のところvenvを使用して手作業で環境を作成することに頼っています。

+1してvenvを使用します。
virtualenvの多くWONTFIXのバグを持っています。
pipenvは、WindowsStoreのPython3.7を使用するWindows10で完全に役立ちます（virtualenvバグ＃1362 ）。

virtualenvはvenvモデルに移行しています-https ：//github.com/pypa/virtualenv/issues/1366を参照して

- - - - - 転送メッセージ - - - - -
投稿者：ダン・ライアン[email protected]
日付：2018年11月26日月曜日、午後2時39分
件名：Re：[pypa / pipenv]可能な場合はvirtualenvの代わりにvenvを使用してください（＃15）
宛先：pypa / pipenv [email protected]
Cc：購読済み[email protected]

正しいようです、私はtoxに回避策があるのを見たので、多分それは
誰かがそれを移植しました

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/pypa/pipenv/issues/15#issuecomment-441533872 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AqyQvrs-RNNTb1YhxaDCWDLpRxrZLKoxks5uy4ydgaJpZM4Lqk2f
。