web-dev-qa-db-ja.com

Python venvとvirtualenvwrapperの組み合わせ

Python 3.5では、仮想環境を作成するための推奨される方法は、 virtualenv ではなく venv を使用することです。それでも pythonパッケージチュートリアルでは両方のツールについて説明しています。

ただし、 virtualenvwrapper は、virtualenvを使用するときに使用する推奨ラッパーツールです。

私の質問は次のとおりです。

  1. Venvでvirtualenvwrapperを使用する方法はありますか？
  2. または、venvのためにvirtualenvwrapperが不要であると考えることさえできますか？ （これは別の問題を解決するラッパーであるため、これがどのように当てはまるかわかりません）

編集：私の質問への回答に混乱があることがわかります。上記のリンクで説明されているように、venvはPythonのvirtualenvの公式な同等物です。複数のスタックオーバーフローの質問は、venvを使用する必要があることを示唆しています。あなたが提案した「複製」で述べたように：

venvの導入は、その混乱への対応の一部です。状況を改善したい場合は、venvを使用して、他の人にも同じことをするように勧めることをお勧めします

したがって、venvを使用することをお勧めします。しかし、この質問が示すように、venvを使用する場合、virtualenvwrapperのようなラッパーをどのように使用しますか

pythonpython-3.xvirtualenvvirtualenvwrapperpython-venv
15
user1853417

追加 このスクリプト を.bashrc/.bash_profile/.zshrcに追加すると、venvの基本的な管理が可能になります。

さらに、次の行を追加してスクリプトを拡張し、既存のvenvリストも表示するようにすることができます。

lsvenv(){
    ls $VENV_HOME
}
5
Memin
  1. Venvでvirtualenvwrapperを使用する方法はありますか？

はい。 WORKON_HOMEをvenvsディレクトリにポイントするだけです。これが私の~/.zshrcで行うことであり、virtualenv（今ではまれですが、いくつかのレガシーpy2のニーズのためだけに）とvenv（最も一般的）を組み合わせて使用​​しています。デフォルトの名前を.venvsに変更して、これらがほとんどPython 3 venvsであり、virtualenvsではないことを明確にしました。

# Python Environment Handling
export WORKON_HOME=$HOME/.venvs  # Default name changed from virtualenv to highlight I am using python3 -m venv (aka pyvenv)
export PROJECT_HOME=$HOME/dev
source /usr/local/bin/virtualenvwrapper.sh  # symlinked to /Library/Frameworks/Python.framework/Versions/3.7/bin/virtualenvwrapper.sh
  1. または、venvのためにvirtualenvwrapperが不要であると考えることさえできますか？ （これは別の問題を解決するラッパーであるため、これがどのように当てはまるかわかりません）

venv == virtualenv（要するに）。 virtualenvがvirtualenvwrapperに取って代わるのと同じ理由で、venvはvirtualenvwrapperに取って代わりません。これに対するあなたの勘は正しいです。

  1. これは、アクティベートをソースとするエイリアスを作成するよりも優れていますか？

必要なものを決定するのはあなた次第ですが、zshプラグインvirtualenvとvirtualenvwrapperを備えたvirtualenvwrapperは、生のエイリアスよりもかなり優れていると思います。

workonですべてのvenvを一覧表示すると非常に便利です。次に、workon speech_analyzerですぐに表示されます。

  1. 他の解決策？

ディレクトリの変更時にvenvをアクティブにするフックを設定することもできますが、それが目的であり、それだけである場合、それは本質的にpipenvです。それがあなたがしたいすべてであるならば、Pipenvは素晴らしいです。 Pipenvには、興味深く有望なロックファイル機能もありますが、開発には遅すぎ、本番環境の問題が未成熟であるため、現時点ではコメントできません。

しかし、ここに示したのと同じ理由で、プロジェクトワークフローごとに1：1の環境が好きだったことはありません： https://chriswarrick.com/blog/2018/07/17/pipenv-promises-a-lot-delivers -非常に小さい/ 。特にこれらのニーズは、マルチプロジェクトの単一環境の私のものと一致しています： https://chriswarrick.com/blog/2018/07/17/pipenv-promises-a-lot-delivers-very-little/#nikola

私のマシンには6つの環境があり、約20のプロジェクトがあります。 Pipenvはそのような状況には及びません。 Pipenvは、20のプロジェクトに対して20の環境を主張しています。それは機能せず、解決するよりも多くの問題を引き起こします。現在1：1のワークフローがある場合は、pipenvが必要なツールになる可能性があります。注意点として、残念ながら、pipenvでそのワークフローを実行できるのは〜のみ〜です。

2
SwimBikeRun

[編集、7月8日19日：読者はおそらく この回答 がPythonで仮想環境を処理するためのさまざまなツールのより完全な説明を提供していることに気付くでしょう。 「環境」の概念がやや洗練されているコンダと同様に、それらすべてに問題があります。]

  1. その名前が示すように、virtualenvwrapperはそれが依存するvirtualenvをラップするように特別に設計されました。まだ誰も同じようにvenvをラップしているとは思いません。

  2. venvは、仮想環境を作成する基本的な作業を行うことを目的としていますが、環境管理はスクリプトを使用して行う必要があります。シェルスクリプトは多くの場合、人々の最初の手段ですが、venvモジュールには、これらのタスクを支援するための広範なAPIがあります。

現在、Python仮想環境を作成するための多くのオプションがあります。あなたが言及したものに加えて、anacondaは環境の作成と管理を可能にし、pipでもかなりうまく機能しますほとんどの時間。

仮想環境空間のツールは、標準のPython配布ツールと可能な限り連携するように設計されていますが、venvがPython 3.5は、virtualenvまたはvirtualenvwrapperのいずれも無効にしませんでしたが、どちらも正常に機能するはずです。

venvモジュールは、主にプログラム内でvirtualenvを作成できるようにするための単純なツールキットであり、virtualenvwrapperの利便性を置き換えることを意図したものではありません。それは単に、かなり異なる一連のニーズを満たしています。

0
holdenweb