pipenv run {whatever}があなたの欲しいものだと思います。

どのプロジェクトの環境を使用するかをどのようにして知ることができますか？

Pipfileが含まれているディレクトリから実行します。

密集して申し訳ありませんが、crontabからそれを行うにはどうすればよいですか？

@ cjw296 cd some/project/dir && pipenv run scriptで十分です。

それは...Pythonパッケージの世界で最新かつ最高のものから私が望むよりもエレガントではありません。

@cjw296これは私たちがターゲットにしている実装ではありません。 どのように機能させたいかについてより良いアイデアがあれば、PRを確認させていただきます。

あなたはそれが幸せであることを確信していますか？ これは素晴らしい計画のように見えます： https ：//github.com/pypa/pipenv/issues/1049#issuecomment -357103428
@kennethreitzのhttps://github.com/pypa/pipenv/issues/1049#issuecomment-358332237は、あいまいさの点でがっかりし、役に立たなかった。

@cjw296何を指しているのかはっきりしていません。 Jaceの提案は、virtualenv管理に関する機能ではなく、デフォルトの選択を変更することに関するものです。 その号で説明されているすべての部分は、現在ユーザーがすぐに利用でき、ほぼ1年が経過しています。

デフォルトの動作への変更を実装した場合でも、スクリプトを実行するにはディレクトリに移動する必要があります。 それがここの状況をどのように改善するのか私にはわかりません。 明確にしていただけませんか。

venv-in-projectを使用すると、 /abs/path/to/project/.venv/bin/{whatever}をcrontabに入れることができます（同じように、venvサブディレクトリの名前を今のように禁止します）。

さまざまなenv変数をいつ有効にする必要があるのか​​は明確ではありません。 私がvenvを作成しているときに一度？ 使う度に？

前者の場合、おそらく私のユースケースであると思いますが、 pipenv installのコマンドラインオプションであると便利です。

接線方向にのみ関連：現在、開発中にvcsディレクトリの外にあるvenvのコレクションを手動で維持していますが、実際には複数必要です（Pythonバージョンごとに1つが最も一般的です）。 いいえ、私は毒が好きではありません。

@ cjw296スクリプトを直接呼び出していて、 pipenv runを使用していない場合はそうです。 ただし、これは現在のpewのデフォルトにも当てはまります。 pipenv --venvは、crontabに配置できるプロジェクトの場所を示します。

環境変数は、crontabユーザーの.profile 、 .bashrc 、 .zshrcなどで設定する必要があります。 これが完了すると、そのプロジェクトで初めてpipenvを実行すると、そのディレクトリ用にローカルvirtualenvが作成されます。 設定されている環境変数に関係なく、ディレクトリは引き続き存在しますが、変数が存在する場合にのみ、pipenvによって使用されます。

前号で説明したように、これらは通常、バイナリの選択肢です。 人々は、プロジェクトを一元化するか、プロジェクトごとに個別に保存することを望んでいます。 変数を設定すると、pipenvはその動作を使用します。 そうしないと、そのフラグを渡すのを忘れたときはいつでも、新しい集中型環境が作成され、それは通常、より苦痛なユーザーエクスペリエンスになります。

複数のvenvを維持することに関して、現在提案されているソリューションはtoxまたはtox-pipenvプラグインです。 これを可能にするためのオプションもpewにあるかもしれません。 現時点で統合しているのはこれらだけですが、より良いオプションがある場合は、提案を検討させていただきます。 ブリードオーバーを避けるために、この問題の主題を維持するようにしてみましょう。

それが環境変数の答えになるのではないかと心配しました。 REQUESTS_CA_BUNDLEで人々が直面する煩わしさのようなにおい; その場合、他のすべての人のようにシステムが提供するSSL証明書を使用するのではなく、環境全体に感染する必要がある魔法。

正直なところ、使用する場所の「タイプ」（たとえば、プロジェクト内、pew経由、（将来的には？）conda経由）は、Pipfileに配置し、実際の場所はPipfile.lockに配置する必要があるように感じます。

私にとって重要なユースケースは、env変数や魔法の作業ディレクトリスクリプトなどを使用せずに、絶対パスのみでエントリポイントスクリプトを使用できるようにすることです。

私もあなたの「二者択一」のコメントについて同意できないのではないかと思います。 私は多種多様なプロジェクトに取り組んでいますが、多くのプロジェクトでそのような決定を下す立場にはありません。 さらに、私にとっての選択は、私が何をしているかによって異なります。ライブラリ開発では、集中型のvenvが必要です。 アプリケーション開発には、ローカル環境が必要です。

この瞬間を利用して、＃1210をもう一度押してみてください。 多くの人がプロジェクトごとの構成を望んでいることは明らかだと思います。 .envは、Pipenvがrunおよびshell以外のコマンドに対してそれを読み取る場合、これらの問題のほとんど（すべてではないにしても）を解決します。

@uranusjrプロジェクトが開始されてから、最初は.pipenvファイルで、後で.envが導入された後、これについて何度か話し合いました。 ケネスは、この種の情報をプロジェクトごとに保存することに強く反対しています。そのため、現在の状態で作業しています。 私はそれが追加の素晴らしいものになることに同意します、しかしそれに対するかなりの需要がありました。

@ cjw296展開に依存しないため、場所はPipfile.lockには含まれません。 Kennethは、Pipfileのすべてのユーザーに当てはまるわけではなく、インスタンス化が1つしかないため、Pipfileに環境の詳細を含めることも望んでいませんでした。

同じユーザーアカウントでさまざまなプロジェクトをホストしている場合、それはおそらく「悪臭」だと思います。 ローカル開発の場合、ケネスはプロジェクト間で交換するための代替オプションとしてdirenvをプッシュしましたが、現時点で私たちが持っているのはそれだけです。

@nateprewitt-ユーザーアカウントごとに1つのプロジェクトのみに取り組んだことがありますか？ 本当に？ 作業しているライブラリごとに異なるユーザーがいますか？

@ cjw296 、戦闘的である必要はありません。 ここでの元の問題からかなり離れていると思います。

システムにPIPENV_VENV_IN_PROJECTを設定していて、それを開発に使用しています。 私はこれをデフォルトにし、プロジェクトレベルのパラメータ化を支持してきましたが、当面はプロジェクトから受け継がれています。

アプリケーション/サービス以外のソフトウェアの開発ワークフローの一部をcronする必要はなかったと思います。 私は通常、実稼働システムまたはローカルでの自動化のためにのみcronを実行します。 最初の例では、はい、さまざまなアプリケーションをさまざまなユーザーに分離します。 2つ目は、コマンドに4文字余分に含まれていても問題はないでしょう。しばらくの間、もう一度確認することはないでしょう。 上で言ったように、これが現状です。 変更に関する提案を確認し、現在の制約を考慮してより良いソリューションに向けて取り組んでいます。

私のコメントを戦闘的であるとみなしているのは興味深いことです。このプロジェクトのメンテナの反応は、多くの問題について同じように感じています。 「変更に関する提案を喜んで検討します」と私は恐れていますが、これを含む多くのケースで生まれたようには見えません。

私がそれを言うとき、私は上記のあなたの特定のコメントを参照しているのではなく、人々が求めているユースケースに対して示されている全体的な非情を参照しています。 他の人が同様の要望を持っている場合に備えて、これは開いたままにしておきますが、今はPipenvを渡して、私のユースケースをよりサポートするものを見つけに行きます。

@ cjw296ネイトが言ったことは、ユーザーごとに1つのプロジェクトでしか作業できないということを意味しているのがわかりません。 私にとってもっと紛らわしいのは、自分のvirtualenvをどこに保存するかを決めることができないプロジェクトで開発しているユースケースです。 それは私がよく知っているワークフローではありません。

あなたが持っている1つのオプションは、pipenvs作成オプションを使用できない場合に、独自の仮想環境を作成することです。 次に、virtualenvにpipenvをインストールして日常の管理を行うことができますが、仮想環境のスクリプトをcronから直接呼び出すことができます。 現在、pipenvは環境を管理するためのCLIアプリケーションであるため、cronから直接スクリプトを呼び出しています。ほとんどの場合、cronの付加価値はわかりません。 これは、pip+virtualenvsを使用していたときに行ったことです。 私は何が欠けていますか？

提案された以上の解決策を喜んでおもてなししますが、すでに検討されていることを明確にしました。 代替案は見たことがありませんが、pipenvは分散プロジェクトチームに制限を設けることを意図したものではないことを明確にしたいと思います。 「バイナリ選択」コメントは開発者システムに適用されますが、それがどのようにすべての人に追随するように強制するのかわかりませんか？

cd some / project / dir &&pipenvrunスクリプトで十分です。

それは少し楽観的だと思います。

cronの一般的にまばらなパスのアイデアと、誰かがpipenvをインストールした方法（たとえば、$＃ sudo pip install pipenvを発行するときにDebianで取得する/usr/local ）の組み合わせを考えると、これはかなり厄介です。 。 私は@cjw296に同意します。pipenvがここでより良い答えを持っていることを望みました。

@JosefAssad cronのパスのまばらなアイデアとはどういう意味ですか？ 作業ディレクトリがプロジェクトのディレクトリである場合、pipenvは関連するvirtualenvを検索します

そして、誰かがpipenvをインストールした可能性のある方法（たとえば、sudo pipinstallpipenvを発行するときにDebianで取得する/usr/ localにあります）。

明らかに、pipenvがcronで使用可能なパス上にない場合は、フルパスで呼び出す必要があります。

cronのまばらなパスのアイデアとはどういう意味ですか

Debianでは、cronパスは/usr/bin:/binです。

明らかに、pipenvがcronで使用可能なパス上にない場合は、フルパスで呼び出す必要があります。

はい、もちろんです。 次に、 pewが見つからないと文句を言います。これsudo pip install pipenv /usr/local $にドロップされ、その時点でcronコマンドでもPYTHONPATHを調整する必要があります（私はこの段階で実験するのに飽きたと仮定します）。 これが、私が解決策を毛深いと説明した理由です。

参考までに、bog標準virtualenvを使用してcronでこれを行う方法もそれほど単純ではありません。virtualenvのアクティブ化スクリプトを入手し、その後フルパスでコマンドを実行します。 ですから、それもきれいではありませんが、私が言ったように、私は、pipenvがここでより良い解決策を持っていることを望んでいました。

@JosefAssadなぜsudoでpipからインストールするのですか？ インターネットから任意のコードにroot権限を与えています。 パッケージが危険にさらされている場合は、setup.pyに配置することを決定したコードを実行するだけです。 公式のPythonドキュメントでは、正確なパスの問題が発生するため、これを行わないことは非常に明確です。

StackOverflowには、*nixのほぼすべてのフレーバーの適切なインストールを詳述する多くの問題があります。

上で述べたように、提案されたアプローチは機能しますが、理想的ではありません。 cronジョブに関するユーザーエクスペリエンスの向上にはあまり重点を置いていません。 これを改善する方法についての提案を確認させていただきますが、「私も」の投稿は実際には会話を進めません。

@nateprewitt安全なLinuxについてのリマインダーに感謝します。 私がそのようにpipenvをインストールしている理由は、pipenvのドキュメントが以下を使用することを示唆しているからです。

pip install pipenv

そのコマンドはDebian（そして最も合理的なLinuxだと思います）では失敗します。 すべてのユーザーが利用できるようにする必要があるため、sudoを使用して、システム全体にインストールします（ pip install -U pipenvではありません）。 幸い、Debianはこれについてかなり正気で、/ usr/localを使用しています。

* nixをインストールするためのヒントについては、stackoverflowを確認します。18年間のLinuxの使用で知っておくべきことをすべて学んだわけではないと確信しています。

とにかく、 id == 0の神々をなだめるためにpip install -U pipenvを決めたとしても、それは「ボートから新鮮な」cronを綴る必要があるPythonパスです（pipenvだけではありません）。しかし、Pythonライブラリの場合も依存します）そして、pipenvを/usr/localにインストールした場合と同じくらい複雑です。

@JosefAssad cronを介してpipenvを呼び出すことについては、まだ完全には確信していません。代わりに、関連するpython実行可能ファイルを直接呼び出すことができるため、その使用法をあまり考慮していないことは明らかです（これは、このような場合に行います）- -この種の方法は、 PYTHONPATHを設定したり、 pewも使用可能かどうかを心配したりする他のすべての質問を回避します。

virtualenvのアクティブ化スクリプトを入手します

好奇心から、あなたはそれを習慣から調達していますか、それともこれはあなたのユースケースに実際に必要ですか？ virtualenv binでpython実行可能ファイルを呼び出し、関連するスクリプトを引数として渡すだけで、同じ目標が達成されますか？

さらに別の代替アプローチとして、次の行に沿って呼び出しスクリプトを作成できます。

#!/bin/sh
VENV_PYTHON="/path/to/project-hAsHpTH/bin/python"
PROJECT="/path/to/some/project"
SCRIPT="script.py"
cd "${PROJECT}" && "${VENV_PYTHON}" "${SCRIPT}"

または、シバンなどでvirtualenvインタープリターを使用するという別のケースもあります。

cronを介してpipenvを呼び出すことについてはまだ完全には確信していません

ええ、私たちがアイデアを出し合っていることを嬉しく思います。 私もこれを処理しなければならないpipenvと結婚していません、私はただきれいなアプローチを探しています。 私は、pipenvの範囲を管理することが不可欠であることを高く評価し、尊重します。

徹底的に考えるために、cronのユースケースは、pipenvの非対話型の使用から人々が期待することになるかもしれないことの良い例かもしれません。 Dockerfileは、pipenvの非対話型の使用が発生する可能性がある別の領域である可能性があります。

好奇心から、あなたはそれを習慣から調達していますか、それともこれはあなたのユースケースに実際に必要ですか？

それを行うにはもっと良い方法があるかもしれませんが、仮想環境ベースのpythonプロジェクトをcrontabから実行するときは、プロジェクトのbin/activateを調達しています。これは、適切なインタープリターを提供するだけではないためです。 Pythonパスをいじくり回すことなく、そのvirtualenvのパッケージライブラリへの正しいパスを提供してくれます。 これは、virtualenvsのすべてのパッケージをシステムライブラリにインストールしたくない場合に必要です。

virtualenv binでpython実行可能ファイルを呼び出し、関連するスクリプトを引数として渡すだけで、同じ目標が達成されますか？

残念ながら、それは機能しません。また、あなたが提案した（そうでなければ本当にクリーンな）ラッパーも機能しないと思います（私は3倍と4倍の確実性をテストしました）：それはインタプリタのみを指定し、 venvのパッケージライブラリ。

シバンでvirtualenvインタープリターを使用するという別のケースでも

あなたはすでにこれを知っているので私を許してください、しかし私は他の人がこのスレッドを読んだ場合に備えてそれを綴っています：それはちょうど正しいインタプリタを再び選ぶだけで、パッケージの別の場所（venvの場所）にそれを向ける問題を再び残します。

より一般的には、ソースコードでインタープリターの場所をハードコーディングすることを少し躊躇しています。 シェバンが（私が通常書いているように） #!/usr/bin/env pythonと言ってから、 #!/path/to/project-hAsHpTH/bin/pythonと書くよりも、virtualenv/pipenvにenvの設定を正しく処理させるのは本当にきれいです。 project-hAsHpTH/bin/pythonの部分は変更されませんが、 /path/to/は非常にうまくいく可能性があります。

私はそれがすべて少し抽象的なことを知っています。 最小限の例を作成する方が簡単な場合は、そのように言ってください。

非セクイターについてはお詫びしますが、gitの同等のソリューションであると私が思うことを思い出します。 おそらくgitの非対話型使用への賛成として、コマンドラインスイッチ-Cがあります（ここのマニュアルページからコピー）：

Run as if git was started in <path> instead of the current working directory.

git実行可能ファイルは、リポジトリ内で.gitディレクトリを見つけることができるかどうかに依存します。 おそらくこれは、特定のpythonプロジェクトに関連付けられているvenvを識別できるようにする必要があるpipenvに少し似ています。

/etcのような場所に立って、 pipenv --pretend-youre-standing-here=/path/to/project run passwdcleaner.py passwd （Pythonプロジェクトの架空の例です！）のようなコマンドを呼び出すことができれば、そのコマンドラインスイッチ--pretend-youre-standing-hereは次のようになります。 gitの-Cに類似しており、私が知る限り、cronのユースケースに対処し、おそらく、人々がpipenvを使用して終了（試行）する可能性のある他の多くの非対話型の方法にも対処します。

それがpipenvで機能するかどうか、あなたが私よりよく知っていること。 :)

@JosefAssad明確な応答に感謝します-Dockerのユースケースは少し異なります。これは、Dockerコンテナーが通常アトミックであり、多くのユーザーがコンテナー内に--systemをインストールしているためです。 pew呼び出しのユースケースは、あなたが言及してから私が考えていた興味深い点です。現在、実行可能ファイルを見つけるためのロジックがいくつかありますが、これを次の呼び出しに適用しているとは思いません。現在、ピューです。これが、プロジェクトディレクトリに変更しただけでは機能しない理由の1つです。

コンテキストとして、 pipenv run現在次のコードで機能します。

def inline_activate_virtualenv():
    try:
        activate_this = which('activate_this.py')
        with open(activate_this) as f:
            code = compile(f.read(), activate_this, 'exec')
            exec(code, dict(__file__=activate_this))
    # Catch all errors, just in case.
    except Exception:
        click.echo(
            u'{0}: There was an unexpected error while activating your virtualenv. Continuing anyway…'
            ''.format(crayons.red('Warning', bold=True)),
            err=True
        )

which()はproject.virtualenv_locationを使用することに注意してください。これは、 pewへの呼び出しにも依存するpipenv --venvと同じです。

Dockerのユースケースは少し違うと思いますが、多くのユーザーがコンテナ内に--​​systemを使用してインストールしています

ええ、あなたはそれについて正しいと思います。それは、良くも悪くも、ほとんどの人がDockerfilesで行うことでもあります。

私はcronとpipenvを少し叩きました。 これが私のために働くものです：

PATH=/usr/bin:/bin:/usr/local/bin
*/1 *  *   *   *     cd /path/to/project/ && pipenv run python stuff.py

virtualenvまたはvirtualenvwrapperが使用していると思われるいくつかのenvvarを設定解除することで修正した、virtualenvの場所に関してpipenvが混乱するという問題がありました。

あなたは絶対に正しいと思います。ピューの発見可能性を改善することで、上記の例の明示的なパス指定を省略できるはずです。 よく発見されました。 そして、cronの呼び出しは、実際には、多かれ少なかれ、元の提案に減らすことができます。

cd / some / project / dir &&pipenvrunスクリプトで十分です

@JosefAssad -debianでも、virtualenvのbinディレクトリにあるエントリポイントスクリプトへの絶対パスを使用するだけで問題が発生したことは一度もないことを認めなければなりません。

pipenvから必要だと思うのはこれだけです。crontabからpipenvを実行する必要はありません。 それは@richardcooperと@nateprewittからの提案でした。

PIPENV_PIPFILE環境変数もあり、これを設定できます。

@kennethreitz -crontabでどのように使用されるかの例を挙げていただけますか？

理解するのはかなり簡単です:)

pipenvから必要だと思うのはこれだけです。crontabからpipenvを実行する必要はありません。 それは@richardcooperと@nateprewittからの提案でした。

申し訳ありませんが、これを読み間違えている可能性がありますが、crontabからpipenvを実行していない場合、元の問題は何でしたか？

@kennethreitz-多分あなたのために。 私にとって、私がここで質問をしていることを考えると、明らかにそうではありません。

@nateprewitt - https: //github.com/pypa/pipenv/issues/1369#issue-292190514を参照してください。

@ cjw296申し訳ありませんが、それはまだ明確ではありません。 virtualenvの絶対パスを取得するためのプログラムまたはコマンドベースの方法は必要ありません。また、pipenvを使用したくないですか？ これをcrontabでどのように使用するつもりでしたか？

さて、ここでは絵文字の応答だけで対話が停止したので、これを閉じます。

将来の読者のためにこのスレッドを要約すると、現在、スクリプトを実行する方法は2つしかありません。

Virtualenvへのパス

1つは、従来のvirtualenvの場合と同様に、virtualenvパスを使用してインストール済みのスクリプトを実行することです。 この値は、環境変数に関係なく、virtualenvの絶対パスを生成するpipenv --venvコマンドから取得できます。

例えば
/path/of/.venv/bin/python yourscript.py
/path/of/.venv/bin/installed_executable_script.py

Pipenv実行

pipenvを使用してジョブを直接実行する場合は、pipenvがcronユーザーのPATHにあることを確認し、プロジェクトディレクトリに移動して、 pipenv runを使用する必要があります。 これは理想的なインターフェイスではありませんが、cron化されたタスクのオプションとして現在使用されているものです。

例えば
cd /path/to/project && pipenv run python yourscript.py

それらをどのように改善してほしいかについての提案がある場合は、それがどのように機能することを想定しているかを詳述した新しい問題を自由に作成してください。 ありがとう！

@ cjw296この機能がどのように機能するかについてさらに詳しい説明があれば、これについて話し続けてうれしいです。 要件はまだかなりあいまいなので、境界を明確にする必要があります。

$ PIPENV_PIPFILE=/path/to/Pipfile pipenv runもあります。

非常にうまく機能する@kennethreitzに感謝します。 ドキュメントで見つからなかったので、ここにPRがあります。

私もこの問題に苦しんでいます。

cronから次のコマンドを実行する必要があります。

pipenv run python manage.py <my_command>

cronから実行するには、cPanelから次のコマンドを設定しています

cd /path_to _my_project/ && pipenv run python manage.py

しかし、これは機能しません。 だから私は次のようなPythonパスを追加しようとしました

cd /path_to_my_project/ && pipenv run /usr/local/bin/python3.5 manage.py <my_command>

しかし、それは言います、

ImportError: Couldn't import Django. Are you sure it's installed and available on your PYTHONPATH environment variable? Did you forget to activate a virtual environment?

この問題から、pipenvによって作成されたvertualenvパスへのパスを提供する必要があるようです。

/home/user/.local/share/virtualenvs/myapp.com-IuTkL8w_

しかし、cronコマンドでそれを使用する方法がわかりません。

cd /path_to_my_project/ && pipenv run /home/user/.local/share/virtualenvs/myapp.com-IuTkL8w_/bin/python3.5 manage.py <my_command>

また、Issue Trackerはヘルプフォーラムではないため、ヘルプフォーラムとして扱わないことをお勧めします。

venv-in-projectを使用すると、 /abs/path/to/project/.venv/bin/{whatever}をcronタブに入れることができます。

よく繰り返される誤解を正すために、ここでチャイムを鳴らします。 virtualenvは、「activate」が起動されたときにいくつかの変更を行いますが、Pythonインタープリターが直接起動された場合は変更されません。

@JosefAssad cronを介してpipenvを呼び出すことについては、まだ完全には確信していません。代わりに、関連するpython実行可能ファイルを直接呼び出すことができるため、その使用法をあまり考慮していないことは明らかです（これは、このような場合に行います）- -この種の方法は、 PYTHONPATHを設定したり、 pewも使用可能かどうかを心配したりする他のすべての質問を回避します。

virtualenvのアクティブ化スクリプトを入手します

好奇心から、あなたはそれを習慣から調達していますか、それともこれはあなたのユースケースに実際に必要ですか？ virtualenv binでpython実行可能ファイルを呼び出し、関連するスクリプトを引数として渡すだけで、同じ目標が達成されますか？

さらに別の代替アプローチとして、次の行に沿って呼び出しスクリプトを作成できます。

#!/bin/sh
VENV_PYTHON="/path/to/project-hAsHpTH/bin/python"
PROJECT="/path/to/some/project"
SCRIPT="script.py"
cd "${PROJECT}" && "${VENV_PYTHON}" "${SCRIPT}"

または、シバンなどでvirtualenvインタープリターを使用するという別のケースもあります。

@techalchemyの手順に従いました。 ただし、virtualenvの代わりにpipenvを使用しました。 また、pipenvの絶対パスも使用しました。 絶対パスがないと機能しませんでした。 これが私のbashスクリプトです。

#!/bin/sh
VENV_PYTHON="/path/to/pipenv/created/virtualenv/python"
PROJECT="/path/to/project/"
PIPENV="/path/to/pipenv"
SCRIPT="script.py"

cd "${PROJECT}" && "${PIPENV}" run "${VENV_PYTHON}" "${SCRIPT}"

pipenv cronjobのデバッグに苦労したため、これをここに残します。 MacOSの/var/ mail/{username}に出力されるcronジョブ。