これは5.0リリースである必要があります。仮にそれを行うとしたら...魔法すぎると思いますが、同時に、それは本当に素晴らしいかもしれません。 多分それをプロトタイプにしたいと思います。

説明を正しく理解していれば、このユースケースがあります。

pytest-watchは、ファイルが変更されたときにpy.testを再実行するツールですが、 runコマンドを使用すると、pipenvのシェルがアクティブ化されないため、 pipenv run ptwは機能しません。

$ pipenv run ptw

Running: py.test
Error: [Errno 2] No such file or directory: 'py.test'

pytest-watchをpipenvで動作させるための関連パッチ： https ：

私はチートを使用してCDのpipenvをアクティブにします。 ここに関連があるかどうかはわかりません。 bash cdをハックして、魔法を追加します。

function cd {
    builtin cd "$@"
    if [ -f "Pipfile" ] ; then
        pipenv shell
    fi
  }  

そして、魚の殻のために、私たちは今プラグインを持っています！ https://github.com/fisherman/pipenv

そのような空想を望む人はとにかく魚を使うべきです。 閉鎖 ：）

pipenvを試しているときに、この問題に遭遇しました。 それを閉じる理由は...それをうまく言えば奇妙です。

pipenvを開発する代わりに、「より優れたパッケージツールが必要な場合はPythonを使用せず、他の言語を使用してください」と言うようなものです。

https://github.com/pyenv/pyenv-virtualenvを使用してvirtualenvを自動的にアクティブ化します-おそらくこのプロジェクトはそこでの作業を活用して統合できますか？

魚に切り替える傾向はあまりありません-私はhttps://github.com/xonsh/xonshをいじってい

@jcrbenそれは私の思考の列が同様に向かっているところです...それの外見によってpipenvのためにそれを修正するのにそれほどストレッチではないでしょう。

@kennethreitzあなたはこれに完全に反対していますか？

新しい問題を開く必要がありますか、ここで議論を続けて、これを再開する必要がありますか、それとも他の何かですか？

理論的根拠は適切に説明されていると思いますが、もう1つ例を挙げたいと思います。
pipenvに切り替えてから、 pyenvを使用しました。
virtualenvを使用するときのpyenvの優れた機能は、専用の.python-versionファイルが含まれているディレクトリに変更したときの自動アクティブ化

これは非常に便利でした。特に、さまざまなステータスのさまざまなプロジェクトをさまざまなコードで処理する場合は、「適切な」環境をオンにする必要はなく、自動的に実行され、実行するコマンドが1つ少なくなります。

pyenv-virtualenv例のように、これはpipenvによって自動的に行われるべきだと思います。 独立したプラグインをインストールする必要がある場合や、動作を定義する何らかの構成パラメーターを設定したい場合でも問題ないので、魔法を避けていますが、それはユーザーの選択です。 私はそれがデフォルトであるべきであり、おそらくオプトアウトオプションのみであるというケースを引き続きサポートしますが、この機能を削除したいと思う人はあまりいないと思います。

venvの「ファンシーネス」を自動的にアクティブ化するにはどうすればよいですか？ これは私が何度も実行したくない基本的な操作であり、事実上「シェルのLOLを移行するだけ」でこの問題を解決するのは少し気難しいようです。

@JohnVonNeumann実際に実装しようとするまでは、これは

@uranusjrこれは

これを言うと、何かを構築するのが難しい場合は、そうです、それは事実です。 しかし、私が少し戸惑うのは、これが事実である場合、人々はこれを言うべきであるということです。 「ああ、これは難しいだろう、とにかく役に立たないだろう」だけではありません。 仕事で難しいチケットを渡されるたびにこれをやったら、仕事がありません。

そして、あなたがここであなたのコメントで述べようとしている点に感謝することができます、そして私はそれから多くの良い実用的な使用を得るので、私はこのような機能を100％助けたいです、私は自分で作ったわけではないので、コメントが少し苦手ですが、意見は許されません。 これを提起したのは私だけではありません。実際、私が見る限り、私たちの意見では私たちが過半数を占めているように見えます。 OSはコミュニティのコンセンサスに関するものだと思いましたか？ 機能についてヘルプが必要な場合は、それを要求します。拒否するだけでなく、役に立たないかのように行動します。

これは、実装が簡単かどうかにかかわらず、設計上の理由から範囲外です。 人々をサブシェルに強制する計画はありません。そのため、Pipfileにpipenv runとscriptsセクションがあります。

私の場合、@ Blue-Dog-Archoliteの提案を改善しました。 これが私の.zshrcです：

function auto_pipenv_shell {
    if [ ! -n "${PIPENV_ACTIVE+1}" ]; then
        if [ -f "Pipfile" ] ; then
            pipenv shell
        fi
    fi
}

function cd {
    builtin cd "$@"
    auto_pipenv_shell
}

auto_pipenv_shell

スニペット@caioariedeに感謝し

また、pipenvに完全に切り替えることができないため、virtualenvsを管理するためのいくつかのメソッドを追加しました（ pipenv shellはatmが遅すぎます）。

`` `bash

現在のフォルダのpipenvvirtualenvをアクティブにします

または明示的なvirtualenv名を受け入れる

workon（）{
if [$＃-eq 0]
それから
ソース$（pipenv --venv）/ bin / activate
そうしないと
ソース〜/ .virtualenvs / $ 1 / bin / activate
fi
}

virtualenvエイリアスの作成

mkvenv（）{
cd〜 / .virtualenvs
virtualenv "$ @"
CD -
workon "$ 1"
}

自動virtualenvソーシング

関数auto_pipenv_shell {
もしも [ ！ -n "$ VIRTUAL_ENV"]; それから
if [-f "Pipfile"]; それから
ワークオン
fi
fi
}
関数cd {
内蔵CD「$ @」
auto_pipenv_shell
}
auto_pipenv_shell

誰かがこれらのwikiエントリを追加できれば素晴らしいです！

私は1つ作成しました： https ：

たぶんhttps://github.com/MichaelAquilina/zsh-autoswitch-virtualenvは誰かのインスピレーションになるかもしれません。

私は次のことを提案するかもしれません（.zshrcと多分.bashrcで動作しますか？）：

# automatically run "pipenv shell" if we enter a pipenv project subdirectory
# if opening a new terminal, preserve the source directory
PROMPT_COMMAND='prompt'
precmd() { eval "$PROMPT_COMMAND" }
function prompt()
{
    if [ ! $PIPENV_ACTIVE ]; then
      if [ `pipenv --venv 2>/dev/null` ]; then
        export PIPENV_INITPWD="$PWD"
        pipenv shell
      fi
    elif [ $PIPENV_INITPWD ] ; then
      cd "$PIPENV_INITPWD"
      unset PIPENV_INITPWD
    fi
}

@ ethanj〜wikiに追加してください：）〜追加しました。

ちょっと@uranusjrwikiエントリを追加してくれてありがとう！ ちょっとした詳細ですが、あなたは私を@joaqoではなく@joapoと

修正済み—本当に申し訳ありません。

これが適切な場所かどうかはわかりませんが、pipenvに切り替えようとしていますが、サブシェルに切り替えるか、Pythonを使用する可能性のあるすべてのコマンドの前に「pipenvrun」を付けるのは面倒です。 zshを使用すると、シェルにかなりの量の状態があります。履歴、ディレクトリスタック、その他のものです。もちろん、ターミナルを終了したり、新しいvirtualenvに切り替えたりするために二重に終了する必要があります。 通常どおりに機能するためにサブシェルにポップインする必要があるのは、「source $（pipenvshell-vars）」よりもはるかに悪いことです。 人々が同じシェルで切り替えることができるように「pipenvshell-vars」コマンドを実装することについて何か考えがありましたか？

xonshの自動アクティベーターを作成しました

@uranusjr wikiページに以下を追加することを検討し

# xonsh
[xontrib-apipenv](https://github.com/deeuu/xontrib-apipenv) by <strong i="10">@deeuu</strong>

たぶんhttps://github.com/MichaelAquilina/zsh-autoswitch-virtualenvは誰かのインスピレーションになるかもしれません。

これは、「pipenvで作成されたvirtualenvsも検出して自動アクティブ化する」ため、非常にうまく機能しているように見えます。 @uranusjrこれをウィキに追加して

wikiページで提案されたソリューションに満足できなかったため、 pipenv-activateを作成しました： https ：

pipenv-activate.shは、現在のシェル内のPipenvプロジェクトの仮想環境を手動または自動でアクティブ化および非アクティブ化する関数を含むPOSIXシェルスクリプトです。

pipenv shellとは異なり、仮想環境は現在のシェル環境に直接ロードされるため、仮想環境がアクティブ化されたときに新しいサブシェルを開始しません。

pipenv runまたはpipenv shell同様に、 .envが存在する場合、仮想環境がアクティブ化されたときにロードされます。

pipenv-activateは、すべてのPOSIXシェル、特にbash、zsh、ksh、dash、ashと互換性があり、単体テストされています。

これは、 oh-my-zshおよびoh-my-bashのプラグインとして使用できます。

Intersecでは60人以上が問題なく毎日使用しています。

それをwikiページに追加するのは素晴らしいことです。

ありがとう@nicopauss！ ウィキにpipenv-activateを追加しました。