Pipenv: pipenvは現在のプロジェクトのvirtualenvをどのように知っていますか？

virtualenvの名前は、プロジェクトのルートディレクトリ名に、プロジェクトルートへのフルパスのハッシュを加えたものです。 これにより、プロジェクトを移動しない限り、名前が一意で予測可能であることが保証されます。 （AFAICTこの名前生成ロジックは、信頼できない実装の詳細です。）

パッケージの特定のバージョンをインストールするには、pipおよびrequirements.txtの場合と同じ構文を使用します（例： pipenv install django==1.11.0 。

@uranusjrこれは、ディレクトリの名前を変更すると、プロジェクトのvirtualenvが失われることを意味します。 それは良くないね。 ディレクトリの名前を変更することは一般的な使用例であり、ユーザーはこれに陥り、環境がどのように機能しなくなったのか疑問に思うかもしれません。

可能であれば、それを修正してPipfileにエントリを作成することをお勧めします。 または、別の.pipenvファイルを作成して、そのようなメタデータを各プロジェクトディレクトリに保存します。

何を指示してるんですか ？

両方の質問に答えてくれてありがとう！

ねえ@ sachinjain024 、ローカルメタデータファイルについていくつか議論しましたが、メンテナのコンセンサスは、pipenvが現時点ではそれをサポートしないというものでした。

プロジェクトを識別するディレクトリパスは、同じ名前のプロジェクト、または同じプロジェクトの複数のコピーが環境状態の誤った上書きを引き起こしていたため、初期に実装されたものでした。

実際には、場所が環境の一部であることに問題を抱えている人は、黙って作業を上書きするよりもはるかに少ないことがわかりました。 Pipenvは結局のところデプロイメント管理ツールであるため、ディレクトリの移動は1つのコマンド修正である必要があります。

@nateprewittに感謝します。 簡単な実装にすばやくジャンプするのは理にかなっています。 後でプロジェクトの名前を変更すると、環境が存在しないことを意味します。

では、この状況で私は何をすべきでしょうか？

1. パッケージ情報を含むPipfileがすでにあるので、環境を再セットアップします。これにより、環境を簡単にリセットできます。
2. どういうわけかvirtualenvディレクトリの名前も変更します
3. ???

この場合、あなたは何を提案しますか？ 将来このような状況になった場合に備えて、興味があります。

pew cpを使用して、既存のvirtualenvを簡単にコピーできますが、1。は、より「標準的な」方法だと思います。

@ sachinjain024 、プロジェクトディレクトリを移動する必要があるときはいつでも、 pipenv installを実行するだけで作業状態に戻ることができます。 これにより、新しいハッシュを使用して環境が作成され、ロックファイルから以前に作成されたインストールと同じようにすべてが再インストールされます。

これを頻繁に行う場合は、 pew rm old_project-a3de90を使用してクリーンアップすることをお勧めします。

pipenvの外部で仮想環境を変更する場合を除いて、 pew cp使用はお勧めしません。 その場合、確実に説明できないあらゆる種類の変更があるため、「保証の無効化」シナリオを考慮する必要があると思います。

@ nateprewitt @

これは、これまでのところpipenvから出てきた最悪のアイデアの1つです。 理由は次のとおりです。

私は、Pythonが多くの内部プロジェクトのテスト自動化に使用されている会社で働いています。 通常、1人のテスターがそれらの12個を処理します。 慣例により、プロジェクトのすべてのテストコードはtestsというディレクトリにあります。 つまり、各テスターに​​は、 ~/.local/share/virtualenvs/tests-hKjFddnZようなものと呼ばれる一連の仮想環境があります。 仮想環境の切り替えを忘れるのは人間の性質であるため、数日ごとに別のワークステーションに呼び出されます。そのワークステーションの担当者は、必要なパッケージをインストールしたと考えて、 pipenv install 。ただし、コードのインポートは機能しません。 それだけでなく、孤立した仮想環境は時間の経過とともに蓄積されますが、それらはすべてわかりにくい名前を持っているため、使用されていない環境を削除するのか、実際に使用されている環境を削除するのかを判断する方法はありません。 つまり、CIでは、毎日数百とは言わないまでも数十の仮想環境を作成します。 本質的にランダムな名前を持つ環境を誰もが追跡できる方法はありません。また、名前が多すぎるため、少なくとも1日に1回はすべてを削除する必要があります。 pipenvとそれを使用することを決定した当社の誰かによって行われたこの非常に賢明な決定のためにのみ、待ち時間に莫大な料金を支払います...

bashrc / shell構成でexport PIPENV_VENV_IN_PROJECT=1を設定します。
（または、シェルスクリプトを変更して、$ PROJECT /.venvにvenvを作成してから
pipenvにはそれがあります）
6:28で月、2018年3月19日にはwvxvw [email protected]書きました：

これは、これまでのところ、pipenvから出てきた最悪のアイデアの1つです。 理由は次のとおりです。

私はPythonが多くのテスト自動化に使用されている会社で働いています
内部プロジェクト。 通常、1人のテスターがそれらの12個を処理します。 沿って
慣例では、プロジェクトのすべてのテストコードはtestsと呼ばれるディレクトリにあります。
これは、各テスターがすべての仮想環境を持っていることを意味します
〜/ .local / share / virtualenvs / tests-hKjFddnZのようなものと呼ばれます-
驚くばかり！ 仮想環境の切り替えを忘れるのは人間の本性なので、
数日おきに別のワークステーションに呼ばれるのはその人が
そのワークステーションで、必要なパッケージをインストールしたと考えます。
pipenv installを実行しましたが、コードのインポートが機能しません。 だけでなく
つまり、孤立した仮想環境は時間の経過とともに蓄積されますが、
それらの中にはわかりにくい名前が付いているので、削除しているかどうかを判断する方法はありません
使用されていない環境、または実際に使用されている環境。 この
つまり、CIでは、数百ではないにしても数十の仮想環境を作成します
毎日。 誰もが持っている環境を追跡できる方法はありません
本質的にランダムな名前であり、それらの数が多すぎるため、
少なくとも1日に1回はすべて削除してください。 待ち時間に多額の費用を支払う
pipenvと誰かによってなされたこの非常に賢い決定のためだけに
それを使うことにした私たちの会社...

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

@jtratnerでは、仮想環境を手動で作成する場合、なぜpipenvが必要なのですか？

仮想環境はそれ自体が作業の一部です。 それはどこでも不完全であり、Windowsでは壊れています（MS Windowsでは、すべての場所で、デフォルトのホームディレクトリは「〜」と呼ばれていると想定しています）。 誰かがPIPと仮想環境をやり直した場合、前任者の明らかなエラーを修正してくれることを期待していました...代わりに、この混乱に非互換性の層が加わっています。

あなたは間違った仮定をしています。 Pipenvはvirtualenvもpipもやり直しません。 それはそれらの上に構築されます。

@uranusjrは読解の問題です。 私はpipenvが何をするのかをよく知っています。なぜなら、私は自分が望むよりもはるかに多くの時間をコードのデバッグに費やしているからです。 仮想環境とPIPをやり直すことが、プロジェクトの目標です。 それは、それらを修正する代わりに、それらを「そのまま」使用することを決定したことは、 pipenv別の大きな間違いであり、続いてclickライブラリを使用し、リストは続きます。

仮想環境とPIPをやり直すことが、プロジェクトの目標です。

誰かがこれをどこに述べましたか？

また、この動作は奇妙であることがわかりました。 pipenvがvirtualenvディレクトリの標準名を選択し、ディレクトリを現在のディレクトリに配置することを期待していました。これは、 npmがnode_modules使用する方法と似ています。

@Flimm export PIPENV_VENV_IN_PROJECT=1 。 ドキュメントを読んでください。

@uranusjr https://docs.pipenv.orgとhttps://docs.pipenv.org/basics/をすべて読みましたが、見逃さない限り、 virtualenvディレクトリがインストールされている場所については言及されていません。また、プロジェクトディレクトリの名前を変更したり移動したりすると、 virtualenvディレクトリを再作成する必要があることを警告することもありません。

PIPENV_VENV_IN_PROJECTいるので紛らわしい名前が付けられ、 pipenv使用していませんvenv標準ライブラリで出荷し、それが使用していますvirtualenv別のプロジェクトです。

このプロジェクトに慣れているので、つまずいたことについてフィードバックを提供しようとしています。

@Flimmのポイントは、この情報を抽象化することです。 virtualenvsを管理する他のツールがどのように機能するかを知っている場合は、virtualenvsのフォルダーを移動するとそれらが見つからなくなることをすでに知っているはずです。 慣れていない場合は、そもそもこれを掘り下げることはないでしょう。

virtualenvsの生成に使用するバックエンドライブラリと環境変数の命名に関しては、前者はそれほど重要ではなく、後者は広く受け入れられている省略形です。 詳細は重要ですが、これが問題を引き起こしているとは思われません。主な反対意見は、Python実行可能ファイルをフォルダーに配置するために使用するバックエンドがわからないことに基づいているようです。 バグに遭遇した場合は報告してください。 _理由だけで_環境変数を変更するつもりはありません。

環境変数は、次のドキュメントですぐに入手できます。http： //pipenv.readthedocs.io/en/latest/advanced/#configuration -with-environment-variablesなので、表示されていない場合は、おそらくすべてを読んでいません。それ

@techalchemy他のツールでは、 virtualenvwrapperようなものを意味していると思います。 私はvirtualenvwrapper使わずに何年も行きました。 Node / NPMのnode_modulesパターンに精通しているPython開発者の数は、 virtualenvwrapperまたはpipenv精通しているPython開発者の数よりも多いと思います。

別の号＃1919のPIPENV_VENV_IN_PROJECTの名前付けで、 virtualenvではなくvenvへの紛らわしい参照についてコメントしました。 言うまでもなく、私はあなたが私が持っていると思う立場を完全には持っていません。

いずれにせよ、元の問題の質問に答えます。 私はこの議論を長引かせたくありません、あなたがそれを望むならば、最後の言葉を自由に持ってください。

これは間違った聴衆であることは理解していますが、この議論が続いているので...まあ、 node_modulesがvirtualenvではなく、 pipenvインスピレーションだったとは思いませんvirtualenvどちらか。 私の推測は歴史的に間違っているかもしれませんが、 rbenvとvirtualenv両方で作業する必要があるため、 virtualenvは理解のない悪いコピーのように感じるか、おそらく初期のプロトタイプで、 rbenvによって改良されました。 いずれの場合も、 virtualenvはrbenvと比較して笑い株であり、その理由は次のとおりです。

環境ごとにパッケージをコピーします。 これは愚かで、遅く、混乱を招きます。 これは単に悪い設計上の決定ですが、おそらく決定の欠如です。誰かがこれらのパッケージを任意のディレクトリに配置するためのコードを書いたため、そのように起こったのです。 その上、Windowsでは実際には機能しません。 Windowsで実際にテストされたことがないという点まで... OSをテストし、Windowsで実行されていることを検出すると、ホームディレクトリを~に設定します。これはデフォルトです。後でいくつかの環境変数によってオーバーライドされる可能性がありますが、実際に監視されたクリーンな環境で自動化を実行しようとしている場合... virtualenvは、同じディレクトリにパッケージをインストールすることはありません。

だから... pipenvは、 requestsのような人間のためのツールであると主張しています...私は推測しますか？ だから、それは前任者によってなされた未熟な努力を改善するべきです...まあ、あなたがあなたの前のものと同じことをするプログラムを作りたいなら、それは行く方法のようですが、より良いです、正しい？ それでも、 virtualenvのゴミを捨てる代わりに、そのまま使用します。 ラッパーは、ラップされたプログラムの一部の関数の使用を許可/困難にするという点で、ラップされたプログラムとのみ異なります...

私の人生では、自動化を行う試みがたくさんありましたが、それはひどいことでしたが、皆さんは星を狙っています。有用な情報を掲載する前であっても、これらの不当な評価をすべてサイトに掲載します。 しかし、あなたは約束を果たしていません。 実際には、実際の作業を行うことなく、世論を操作するだけです。 そして今、自動化をしなければならないプログラマーは、誰かがGitHubでもっと「いいね」を取得したかったという理由だけで、別の悪に直面する必要があります...

@wvxvw確かにあなたは間違っています。 virtualenvはrbenvより5年（4年、以下を参照）ほど前のものであるため、それに触発されることはありません。 また、それらは根本的に異なるものであり、最終的には同様の目標を達成するだけです。 あなたが探しているのは（rbenvに触発されたランタイム管理ツール）pyenvです。

また、virtualenvが他のツールと同等ではないことについても、10年前から存在していることをご存知ですか。 ソフトウェア開発の要件は大きく変化し、それが行った仮定は徐々に時代遅れになり、誰もそれを置き換えるためにステップアップすることを気にしませんでした。 あなたはステップアップするのに十分気にしていますか？

誰もが話す機会に値することは理解していますが、トピックを最小限に理解せずにディスカッションに参加し、すぐに指を指し始めることは、Pipenv、virtualenv、およびPythonパッケージングシステム全体の貢献者にとって非常に失礼です。 これをしないでください。

編集：私はいくつかの掘り下げをしました。 virtualenvの最初のリリースである0.8は2007年に作成され、rbenv（0.1）は2011年であったため、5年ではなく4年離れています。

@wvxvw私はあなたが侮辱を提供するのを見ただけです。 このような態度は、ここではあまり歓迎されません。 投稿を続ける前に、行動規範をご覧ください。

プロジェクトパスを変更した後も同じ問題が発生し、元のvirtualenvマッピングが失われた後、このスレッドを読みました。 まず、pipenvチームの仕事に感謝します。 この議論について共有したいいくつかの意見があります：

1. このドキュメントでは、プロジェクトパスとenvの間のマッピングメカニズムを指摘し、少なくともユーザーにchanging project path would cause unmapping the original envことを警告する必要があります。

2. Pipfileでenvへのパスを手動で設定できるとよいでしょうか？ つまり、同じ環境を手動で使用するには、特別な要件がある場合があります。

皆さんと共有する私の意見です。

pipenvの使用方法は完全に不明です。 1つのプロジェクトに多くの仮想環境を用意する必要がありますか？ プロジェクト間で仮想環境を共有する必要がありますか？ Pythonバージョンがそのプロジェクトにのみ必要な場合、pipenvを使用して特定のプロジェクトに別のPythonバージョンをインストールするにはどうすればよいですか？ 他の人がどこから来ているのかを理解しようとせずに、他の人についてたくさんのことを想定して、誰もがこのスレッドで自分自身でいっぱいです。 ホームページでpipenvの褒め言葉を読んだとき、それが私に役立つと信じていました。 代わりに、私はそれと格闘するのに5日間を無駄にしました、そして今、それが少なくともいくらか決定論的だったので、私はpyenvに戻ると思います。

1つのプロジェクトに複数の環境を使用する場合は、toxを使用します。 メインの開発環境にはpipenvを使用し、複数のPythonバージョンでのテストにはtoxを使用します。

@ashnurあなたは明らかに何かをする必要があります。 ボランティアが運営するオープンソースプロジェクトにネガティブなものを広めるのではなく、何か役に立つものを提供してみませんか？

@uranusjr
これはハッシュが発生する場所ですか？

私はプロジェクトに取り組んでおり、パスのハッシュを計算する必要があります。

@devxpyうん、その通り。

皆さんは、pipenvを使用してvirtualenvをセットアップする方法について、基本的なチュートリアルを作成する必要があると思います。これは、人々にとって使いやすいため、より多くの人々がそれを使用するためですが、混乱を引き起こす場合は、より多くの人々がそれを使用せず、他の人を探す可能性がありますそこでプロジェクトを構築するための言語または方法

@uranusjr Pipenvがデフォルトでプロジェクトディレクトリにvirtualenvを作成しない理由は何ですか？ 私の見方では、プロジェクトの名前が変更/移動/削除されたときに、孤立した環境の問題が解決されます。 その上、それがnpmのように機能することを（ある程度正当に）期待している人々にとってはそれほど混乱しないでしょう。

多分伝統以外にこのアプローチを好むことには何か利点がありますか？

pipenvinstallコマンドの前に.venvディレクトリを作成するだけです。 pipenvインストールの—venvまたは—dot-venvオプションは、実際には歓迎されます:)

2018.10.9以降、これを行う別の方法があります。 仮想環境へのパスを含む.venvファイルを追加できます。 （卑劣な新機能！）

@andrewpeterprifer以前はこれを行っていたため、非常に強く拒否する人がいたため、変更する必要がありました。 いずれかのアプローチを選択する必要があり、プロジェクトディレクトリ内に仮想環境を配置しない方がデフォルトであると認めざるを得ませんでした。

psあなた（または誰か）はこれについてのよくある質問のエントリを書くことに興味がありますか？ おそらく数段落かかるでしょうが、誰かがテキストを磨いてPRを提出するのに時間がかかると約束したかどうかを説明したいと思います。

@uranusjrなぜそれがより良いデフォルトであるのか私は非常に興味があります。 私はPythonに比較的慣れていないので、今ではベストプラクティスについて明らかな何かが欠けているように感じます。 ：） ありがとう！

PS：なぜ物事がそうなっているのかを説明していただければ、FAQエントリを書くことができます。 ;）

2018.10.9以降、これを行う別の方法があります。 仮想環境へのパスを含む.venv _ file_を追加できます。 （卑劣な新機能！）

@andrewpeterprifer以前はこれを行っていたため、非常に強く拒否する人がいたため、変更する必要がありました。 いずれかのアプローチを選択する必要があり、プロジェクトディレクトリ内に仮想環境を配置しない方がデフォルトであると認めざるを得ませんでした。

psあなた（または誰か）はこれについてのよくある質問のエントリを書くことに興味がありますか？ おそらく数段落かかるでしょうが、誰かがテキストを磨いてPRを提出するのに時間がかかると約束したかどうかを説明したいと思います。

ぶつかってすみません... pipenvで作成された仮想環境を持つプロジェクトフォルダを移動するのとまったく同じ必要があります。

現在、私は次のことを行っていますが、まったく問題はありません。

• プロジェクトフォルダを好きな場所に移動します
• C：\ Users \ user \ .virtualenvsで移動したプロジェクトに関連付けられているvenvのフォルダーを削除します
• cmdを使用して新しいプロジェクトフォルダーの場所に移動し、pipenv install（またはpipenvshellを実行してからpipenvsync）を実行します

すべて問題なく動作します。 これは悪い習慣ですか？

@uranusjrのコメントに関して、新機能を正しく理解している場合は、.venvファイル（目的の仮想環境へのパスを含む）をプロジェクトフォルダーに追加する必要がありますか？ そして、これは私が以前に会ったすべてのステップをしなければならないことを私が回避するだろうか？ もしそうなら、それは素晴らしいです！
その場合、仮想環境が最初に作成されたときに、そのようなファイルがプロジェクトフォルダーに自動的に作成された方がよいのではないでしょうか。

PS：私もFAQを書きたいと思っています

実際、 @ gioxc88のアイデアは良いと思います。新しく作成されたvirtualenvは、プロジェクトルートの下に.envファイルを自動的に生成でき、 PATHようなenv構成を含みます。 これにより、開発者にとって環境がより透過的になり、再構成するためのより便利な方法になります。

私はあなたの質問に一緒に答えようとします。 アプローチは悪くありません（IMO;私も同じセットアップを使用しています）。 ただし、知らないユーザーがつまずくのは簡単です。

それを考える1つの方法は、プロジェクトをバージョン管理に置くことを検討することです（Gitなど）。 環境がプロジェクトルートで作成されている場合、それは当然リポジトリルートにあります。 この設定に慣れているあなたや私のような人々は、 .venvディレクトリがチェックインされないように、 .gitignore （またはグローバル無視構成）にルールを追加する必要があることを明らかに知っていますが、疑いを持たないユーザーはそうしませんでした、そして偶然に環境を非常に簡単にチェックすることができました。 これはプロジェクト管理に悪いだけでなく、（さらに重要なことに）ローカル情報を公開することによって潜在的な攻撃へのベクトルを提供します。 したがって、プロジェクト管理ツールでは、生成されたファイルをプロジェクトディレクトリ内に配置しnode_modules ）、それを行うことは問題ありませんが（たとえば、NPMの

デフォルトでプロジェクトルートの外部で環境が生成されている場合、プロジェクトを公開するときに心配する可能性が1つ少なくなります（たとえば、プロジェクトをGitHubにプッシュします）。 それは私たち（プロジェクト内の環境を好む）の生活を少し難しくしますが、リスクの観点から、起こり得る最悪の事態は、プロジェクトを誤って移動して環境を壊したり、プロジェクトが削除されたときに環境を削除するのを忘れたりすることです。 どちらも、潜在的に機密性の高い環境情報を誤ってGitHubにプッシュするよりもはるかに簡単に回復できます。

.venvファイル機能はまだかなり新しく（ほんの数日前にリリースされました）、私たちはまだそれを最大限に活用する方法を模索しています。 .venvディレクトリと同じ問題がありますが、それほど悪くないことを願っています。 私はこの機能が本当に好きで、ユーザーエクスペリエンスを向上させるためにこの機能を使用できることを願っていますが、ここではまだ考慮すべきことがたくさんあります。

こんにちは。私にとっては、.venvディレクトリ（古い機能）と.venvファイル（新しい機能）は問題ありませんが、pipenvinstallコマンドにオプションがあると非常にありがたいです。

何かのようなもの：

pipenv install

~/.local/インストールします

pipenv install --venv

$PWD/.venvディレクトリにインストールします

pipenv install --venv-dir /my/custom-path

/my/custom-pathインストールされます。

新機能が必要な場合は、 ~/.peeps拡張提案を行って、適切に提案してください。 さまざまな問題にランダムに散らばっている拡張提案を作成しないでください。追跡できません。

@uranusjr詳細な回答ありがとうございます！ 私の好奇心を満たすために、チェックインされたpython venvによって、どのような種類のローカル（潜在的に機密性の高い）情報が公開される可能性がありますか？ node_modulesがチェックインされると煩わしいことに同意しますが、通常はローカル情報が含まれていません。

Python仮想環境には、いくつかのシェルスクリプトが含まれています（例： activate ）。 多くの人がそれらを変更して、データベースパスワード、別の構成ファイルへのパスなどを指定する環境変数を追加します。仮想環境でスクリプトを変更することはベストプラクティスに反しますが、それでも人々はこれを行います（そして、それをやめるように指示すると防御的になります-個人的体験）。

また、その通りです。 node_modulesは機密情報が含まれていない可能性があります。 これは、エコシステムをゼロから構築する場合のもう1つの利点です。 残念ながら、Python仮想環境は、これが一般的な問題になる前に発明されました（当時、VCSを使用している場合は、すでに教祖です）。

pipenvが正しいvirtualenvをどのように知っているかを理解しようとしていたときにここに到着しました:)

その議論をありがとうみんな。 おそらく、メインページ（たとえば、ここ）で、プロジェクトパスの名前を変更すると、virtualenvバインディングのデフォルトのメカニズムが壊れることを指定することをお勧めします。

すべてのドキュメントページは寄稿のために開かれています。 物事を求めないでください、それをしてください:)

します！

@uranusjrこれは、ディレクトリの名前を変更すると、プロジェクトのvirtualenvが失われることを意味します。 それは良くないね。 ディレクトリの名前を変更することは一般的な使用例であり、ユーザーはこれに陥り、環境がどのように機能しなくなったのか疑問に思うかもしれません。

可能であれば、それを修正してPipfileにエントリを作成することをお勧めします。 または、別の.pipenvファイルを作成して、そのようなメタデータを各プロジェクトディレクトリに保存します。

何を指示してるんですか ？

両方の質問に答えてくれてありがとう！

両方の質問をしてくれてありがとう。 私も同じ問題に遭遇します、

間違ったディレクトリでpipenvを初期化し、正しいディレクトリからvirtualenvディレクトリを利用する必要がある場合は、 pipenv --venvを実行し、 PIpfileとPipfile.lockを移動することでvirtualenvパスを取得できます。正しいディレクトリに移動します。

echo ${PATH_OBTAINED_FROM_PREVIOUS_COMMAND} > .venvは正しいディレクトリにあり、正しく機能するはずです。

今日、親ディレクトリにpipfileがある場合、pipenvは環境変数export PIPENV_VENV_IN_PROJECT=1を無視し、代わりに親ディレクトリにvenvをインストールすることに気付きました。 これはリリース2018.11.26ます。 親ディレクトリからpipfileを削除すると、pipenvは文書化されたとおりに機能します。