これが予想される動作であるかどうかはよくわかりませんが、使用法の観点からは、これはバグのようです。
pipenv install <package_name>
virtualenvのを使用して活性化されていても、新たなvirtualenvのを作成していますpipenv shell
。
Pipfile
が配置されているのと同じディレクトリにいない場合。
$ python -V
== 3.6.3$ pipenv --version
==バージョン8.3.1アクティブ化されたvirtualenvシェルを使用している場合、( pwd
関係なく) pipenv install
はそれを尊重し、 Pipfile
を正しく更新する必要があり、新しいPipfile
作成しないでください。
同じアクティブ化されたvirtualenvにあるが、別のディレクトリにある場合でも、新しいPipfileが作成されます。
$ mkdir -p testproject/app
$ cd testproject/app
$ pipenv install flask
$ pipenv shell # environment gets activated here
$ <my_new_environment>$ cd .. # Now we are inside testproject
$ pipenv install requests
$ New Pipfile gets created here
こんにちは@ansrivas! これは、pipenvの意図されたフローではありません。 Pipenvは、最初に仮想環境を検出したが、その後のすべての呼び出しでは検出しなかった場合、仮想環境を使用します。 あなたはvirtualenvsのかなり毛むくじゃらの巣を持っているでしょう! プロジェクトの外部にあるフォルダーに移動すると、pipenvは新しいpipfileを作成します。 フォルダの外にいくつかのパッケージをインストールしたいが、サブシェルでアクティブ化した仮想環境の内部では、 pipenv shell
を実行してからpip install requests
ます。 Pipenvを使用して、プロジェクトのvirtualenvを作成できますが、それ自体はvirtualenvマネージャーではなく、プロジェクトマネージャーです。
@erinxoconそしてここに問題があります:ユーザーはpipenvがpipの代わりになることを期待しています。
@kennethreitzはpipenvホームページでそれを自分で言った:
pipとvirtualenvを別々に使用する必要がなくなりました。 彼らは一緒に働きます。
あなたが言ったように、pipenvはvirtualenvを作成するだけでなく、それを管理することになっています。 繰り返しになりますが、それはホームページで明示的に言及されています(私の強調):
プロジェクトのvirtualenvを自動的に作成および管理し、パッケージのインストール/アンインストール時にPipfileからパッケージを追加/削除します。
昔は、virtualenvとpipを別々に使用すると、任意のディレクトリとpip install
に移動でき、パッケージはvirtualenvに正しくインストールされていました。これは、pipenvがそれを行わないという事実です。 -管理されたvirtualenvがアクティブ化されます_ユーザーの期待を破ります。
これについては@kszeに同意します。
pipenv
がアクティブなvirtualenvを管理しているはずです。
同様の方針に沿って... -r
を使用して、外部のPipfileまたはPipenv.lockを現在のvirtualenvにインストールでき、別の仮想環境を作成できないはずです。
最も参考になるコメント
@erinxoconそしてここに問題があります:ユーザーはpipenvがpipの代わりになることを期待しています。
@kennethreitzはpipenvホームページでそれを自分で言った:
あなたが言ったように、pipenvはvirtualenvを作成するだけでなく、それを管理することになっています。 繰り返しになりますが、それはホームページで明示的に言及されています(私の強調):
昔は、virtualenvとpipを別々に使用すると、任意のディレクトリと
pip install
に移動でき、パッケージはvirtualenvに正しくインストールされていました。これは、pipenvがそれを行わないという事実です。 -管理されたvirtualenvがアクティブ化されます_ユーザーの期待を破ります。