Python 3.3の標準ライブラリには、新しいパッケージが含まれていますvenv
。それは何をしますか、それは正規表現と一致するように見える他のすべてのパッケージとどう違うの(py)?(v|virtual|pip)?env
ですか?
virtualenv
とpyenv
同じ機能を実行していない、とお互いの代替ではありませんありません。私の答えを見てください。
Python 3.3の標準ライブラリには、新しいパッケージが含まれていますvenv
。それは何をしますか、それは正規表現と一致するように見える他のすべてのパッケージとどう違うの(py)?(v|virtual|pip)?env
ですか?
virtualenv
とpyenv
同じ機能を実行していない、とお互いの代替ではありませんありません。私の答えを見てください。
回答:
virtualenv
Pythonライブラリ用の分離されたPython環境を作成する非常に人気のあるツールです。このツールに慣れていない場合は、このツールを学習することを強くお勧めします。このツールは非常に便利なツールです。この回答の残りの部分では、このツールと比較します。
ディレクトリ(例:)に一連のファイルをインストールしenv/
、PATH
環境変数にカスタムbin
ディレクトリ(例:)をプレフィックスとして追加することで機能しますenv/bin/
。python
またはpython3
バイナリの正確なコピーがこのディレクトリに配置されますが、Pythonは、最初に、パスに関連するライブラリを環境ディレクトリで探すようにプログラムされています。これはPythonの標準ライブラリの一部ではありませんが、PyPA(Python Packaging Authority)から正式に祝福されています。アクティブ化すると、を使用して仮想環境にパッケージをインストールできますpip
。
pyenv
Pythonのバージョンを分離するために使用されます。たとえば、Python 2.7、3.6、3.7、および3.8に対してコードをテストしたい場合があるので、それらを切り替える方法が必要になります。アクティブ化されると、PATH
環境変数の前にが付けられます~/.pyenv/shims
。ここには、Pythonコマンド(python
、pip
)に一致する特別なファイルがあります。これらは、Pythonに付属するコマンドのコピーではありません。これらは、PYENV_VERSION
環境変数、.python-version
ファイル、またはファイルに基づいて実行するPythonのバージョンをその場で決定する特別なスクリプト~/.pyenv/version
です。pyenv
また、コマンドを使用すると、複数のPythonバージョンをダウンロードしてインストールするプロセスが簡単になりpyenv install
ます。
pyenv-virtualenv
以下のためのプラグインであるpyenv
のと同じ著者によってpyenv
は、使用できるようにするために、pyenv
そしてvirtualenv
便利に同時に。ただし、Python 3.3以降を使用pyenv-virtualenv
しているpython -m venv
場合は、利用可能であれば、ではなく実行を試みますvirtualenv
。あなたは使用することができますvirtualenv
し、pyenv
一緒にせずにpyenv-virtualenv
使用すると、便利な機能をしたくない場合は、。
virtualenvwrapper
は一連の拡張機能ですvirtualenv
(docsを参照)。それはあなたのようなコマンドを与えmkvirtualenv
、lssitepackages
と特にworkon
異なるの切り替えのためvirtualenv
のディレクトリ。このツールは、複数のvirtualenv
ディレクトリが必要な場合に特に便利です。
pyenv-virtualenvwrapper
ためのプラグインですpyenv
と同じ作者によるpyenv
便利統合するため、virtualenvwrapper
にpyenv
。
pipenv
結合することを目指しPipfile
、pip
およびvirtualenv
コマンドライン上の1つのコマンドに組み込みます。virtualenv
通常、ディレクトリはに配置され~/.local/share/virtualenvs/XXX
、XXX
プロジェクトディレクトリのパスのハッシュになります。これはvirtualenv
、ディレクトリが通常は現在の作業ディレクトリにあるとは異なります。pipenv
(ライブラリではなく)Pythonアプリケーションを開発するときに使用することを目的としています。代替がありますpipenv
など、poetry
この質問だけでも同様に命名されたパッケージについてですので、私はここに表示されません。
pyvenv
Python 3に付属しているスクリプトですが、問題があったため(混乱を招く名前は言うまでもありません)、Python 3.6では非推奨になりました。Python 3.6以降では、完全に同等のものはpython3 -m venv
です。
venv
は、Python 3に同梱されているパッケージであり、使用して実行できますpython3 -m venv
(ただし、一部のディストリビューションではpython3-venv
、Ubuntu / Debian などの別のディストリビューションパッケージに分割しています)。と同じ目的を果たしますが、virtualenv
その機能のサブセットしかありません(こちらの比較を参照)。特に、前者はPython 2と3の両方をサポートしているため、virtualenv
は引き続きより人気がvenv
あります。
これは、初心者のための私の個人的な推奨事項です。Python2 と3の両方で、さまざまな状況で機能するvirtualenv
とpip
から学習し、必要になったら他のツールを選択します。
venv
実際にその問題を解決しましたか?
venv
すると、新しいPythonバージョンに簡単にアップグレードできるようになります。
virtualenv
Python3.3以降の使用は避け、代わりに標準の付属ライブラリを使用しますvenv
。新しい仮想環境を作成するには、次のように入力します。
$ python3 -m venv <MYVENV>
virtualenv
Pythonバイナリを仮想環境のbinディレクトリにコピーしようとします。ただし、そのバイナリに埋め込まれたライブラリファイルリンクは更新されないため、Pythonをソースから相対パス名を使用して非システムディレクトリにビルドすると、Pythonバイナリが壊れます。これはコピー配布可能なPythonを作成する方法であるため、大きな欠陥です。ところで、OS Xの埋め込みライブラリファイルリンクを検査するには、を使用しますotool
。たとえば、仮想環境内から次のように入力します。
$ otool -L bin/python
python:
@executable_path/../Python (compatibility version 3.4.0, current version 3.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.0.0)
その結果、私は回避virtualenvwrapper
しpipenv
ます。pyvenv
廃止予定です。pyenv
どこvirtualenv
で使うのが多いようですが、作り物venv
もやっていると思うので遠ざけておきますpyenv
。
venv
シェルに仮想環境を作成します 新鮮かつサンドボックスで、ユーザー取り付けのライブラリを、そして、それはだマルチのpython安全。新鮮なのは、仮想環境がPythonに同梱されている標準ライブラリでのみ開始されるためpip install
、仮想環境がアクティブな間に他のライブラリを最初からインストールし直す必要があるためです。これらの新しいライブラリのインストールは仮想環境の外には表示されないため、サンドボックス化されています。ベースのPythonインストールに影響を与えることを心配せずに、環境全体を削除して、最初からやり直すことができます。仮想環境のターゲットフォルダーが作成されないため、ユーザーがインストール可能なライブラリsudo
すでに所有しているディレクトリにあるため、sudo
ライブラリをインストールするための権限は必要ありません。最後に、仮想環境がアクティブになると、シェルはその仮想環境の構築に使用されたpythonバージョン(3.4、3.5など)しか認識しないため、マルチpythonセーフです。
pyenv
venv
複数のpython環境を管理できるという点で似ています。ただし、pyenv
ライブラリのインストールを開始状態に都合よくロールバックすることはできないため、admin
ライブラリを更新するには、ある時点で特権が必要になる可能性があります。なので、使うのもいいと思いますvenv
。
ここ数年、私はビルドシステム(emacsパッケージ、pythonスタンドアロンアプリケーションビルダー、インストーラー...)に多くの問題を発見しましたvirtualenv
。この追加オプションを削除してのみを使用する場合、pythonはより良いプラットフォームになると思いますvenv
。
add2virtualenv
の下にPYTHONPATH
カスタム_virtualenv_path_extensions.pth
ファイルを追加して、を微調整しますsite-packages
。または、仮想環境をアクティブにするたびに呼び出すファイルのPYTHONPATH
環境変数を更新することもできbin/activate
ます。またはsite-packages
、追加のディレクトリを指すようにシンボリックリンクを追加することもできます。これらの選択肢はどちらも、開発者がトラブルシューティングに広く使用している従来のコマンドラインツールに対して透過的です。.pth
ドキュメントに記載されていない名前のカスタムを使用すると、より魔法のIMOのように見えます。
PYTHONPATH
、の必要性を回避するための正しいアップデートであることを確認しましたadd2virtualenv
。最初のコメントからのSOの支援の欠如に関して、あなたの投稿をトラブルシューティングするように人々を動機付けるために、私の唯一の提案は、彼らがあなたの問題を解決する場合の賛成投票です?マウスクリックと引き換えに30時間の調査+書き込み?良い取引のように
pyvenv
は非推奨ですpyenv
。これらのツールの名前と混同するのはとても簡単です。
私はpipenv
うさぎの穴を掘り下げました(それは確かに深くて暗い穴です...)、最後の回答が2年以上前なので、Python仮想エンベロープのトピックに関する最新の開発でディスカッションを更新するのに役立つと感じました見つけた。
この答えは、エンベロープソリューションとしてのpipenvとvenvのメリットについての激しい議論を続けることについてではありません。私はどちらも推奨しません。それはPyPAが矛盾する標準を承認し、virtualenvの将来の開発がそれらの間のいずれかまたは両方の選択を否定することを約束する方法についてです。これら2つのツールに焦点を当てたのは、これらがPyPAによって油をそそがれたツールだからです。
OPが指摘するように、envは環境を仮想化するためのツールです。NOTサードパーティのソリューションが、ネイティブツール。PyPA是認venv作成するためのVIRTUAL封筒:「バージョン3.5で変更:venvの使用は、現在の仮想環境を作成するための推奨されます」。
pipenvは -のよう venv -仮想封筒が、さらにロールインパッケージ管理と作成するために使用することができる脆弱性チェック機能を。を使用する代わりにrequirements.txt
、 Pipfilepipenv
を介してパッケージ管理を提供します。以下のよう PyPAがためpipenv是認パッケージ管理を暗示するように見えるだろう、取って代わることです。pipfile
requirements.txt
もつとも:pipenvの用途はVIRTUALENV、仮想封筒を作成するためのツールとして、NOT venvによって承認されたPyPA仮想封筒を作成するためのゴーへのツールとして。
したがって、仮想エンベロープソリューションの解決が十分ではなかった場合、PyPAは、異なる仮想エンベロープソリューションを使用する2つの異なるツールを承認するようになりました。この競合を強調するvenvとvirtualenvに関する激しいGithubの議論はここにあります。
上記のリンクで参照されているGithubの議論により、virtualenvの開発は、将来のリリースでvenvに対応する方向に進んでいます。
組み込みのvenvを優先します。ターゲットpythonにvenvがある場合は、それを使用して環境を作成します(その後、それに続く操作を実行して、提供する他の保証を容易にします)。
したがって、2つのライバルの仮想エンベロープソリューション間に将来の収束があるように見えますが、現時点では、pipenv-を使用virtualenv
- はと大きく異なりますvenv
。
与えられた問題pipenv解きと事実PyPAはその祝福を与えている、表示され、明るい未来を持っています。場合とvirtualenvのは、その提案、開発目標に実現し、仮想封筒のソリューションを選択することは、もはやどちらかの場合あってはならないpipenv OR venv。
2020年4月の更新
私がこの投稿に出くわしたとき、私は同じものを探していました。どのツールを使用するかというこの問題は、私のような新しいPythonユーザーにとって非常に混乱し、難しいと思います。これは、pipenvに関するPyPA Webサイトから直接です。
このチュートリアルでは、pipenvプロジェクトを、主にPythonライブラリ開発ではなくPythonアプリケーション開発のニーズに焦点を当てたツールとして扱いますが、プロジェクト自体は現在、バグ修正や新機能の公開を妨げているいくつかのプロセスとメンテナンスの問題に取り組んでいます( 2019年全体が新しいリリースなしで通過しています)。つまり、近い将来、pipenvには、問題の解決のための明確なタイムラインがなくても、いくつかの癖やパフォーマンスの問題が残っています。
これは現状のままですが、プロジェクトのメンテナは、pipenvの代わりに、またはpipenvと一緒に使用するために、アプリケーションの依存関係を管理するための他のツールを調査する可能性があります。
2020年4月のpipenvリリースが計画どおりに進行し、その後のリリースも順調に進んでいると想定すると、チュートリアルに関するこの警告は削除されます。これらのリリースが予定どおりに進まない場合、チュートリアル自体は削除され、使用可能な依存関係管理オプションに関するディスカッションページに置き換えられます。
pipenv
チームはは、PyPIに2つのバージョンをリリースしました。2020.5.28
最近になって、そして2020.6.2
:pypi.org/project/pipenv/#history