Virtualenv: -再配置可能な代替

再配置可能フラグは常に実験的なものであり、実際に機能することはありませんでした。 サポートが終了し、機能が完全に削除されました（したがってメジャーリリース）。 ユースケースを説明してください。別のアプローチを提案できる場合があります。

CMD export branch && cd /build_dir && \
 apt-get update -y && apt-get upgrade -y && \
 pip3 install virtualenv && \
 virtualenv --always-copy --python=python3 env && \
 git clone http://user:pass@gitlab/dev/repo.git && \
 cd /build_dir/veil-repo/code/veil-common && \
 git checkout $branch && \
 python3 install.py -p /build_dir/veil-repo/code/cli-app/ -v /build_dir/env && \
 python3 install.py -p /build_dir/veil-repo/code/controller/ -v /build_dir/env && \
 python3 install.py -p /build_dir/veil-repo/code/node/ -v /build_dir/env && \
 cd /build_dir/ && \
 ./env/bin/pip3 install -r requirements.txt && \
 virtualenv --relocatable env

これはDockerfileからの抜粋です。 --relocatableフラグを削除すると、コードは正しく機能しますか？ つまり、独自の分離された環境を作成する必要があります。これは、どのような方法でもコピーできます。

Dockerの内部では、90％だと思います。 ただし、そのDockerコードを管理しているユーザーと連絡を取る必要があることを確認するには、再配置可能の処理方法の微妙な違いが実際に発生する可能性があります。

CIシステムが長い名前のディレクトリにvirtualenvを作成するため、この機能を使用することがありました。 名前は十分に長いため、 #!が長すぎて、環境でスクリプトを実行できません。

@ Nitori-そのような場合は、一般的にツールを呼び出すためにpython -m形式を使用することをお勧めします🤔

それは公正です。 多くのPythonパッケージは動作が悪く、そのように呼び出すことはできませんが。

@ Nitori-その場合でも、バイナリフォルダー内のpythonインタープリターを介して実行可能ファイルを呼び出すことにより、いつでも強制的に呼び出すことができます。 例えば

{venv}/bin/python {venv}/bin/bad-bad-tool

ここで、 {venv}は任意の長さにすることができます👍

私の会社では、パイプラインで--relocatableフラグを使用して、virtualenvを再利用し、時間を節約しています。GitLabを使用し、早い段階でvirtualenvを構築し、アーティファクトとして保存してから、再利用して並列テストの束。

virtualenvのバージョンを固定するつもりでしたが、バグのために最新のものをプルすることになり、今朝パイプラインが壊れました。 そのバグを修正して固定し、すべてが実行されるようにしました。フラグが削除されるのを回避する方法を見つけます。 しかし、問題が解決され、フラグが今後サポートされることを期待していなくても、私の経験を伝えるためにここに注意したいと思いました。

virtualenvを作成する新しいアプリデータシーダーは100ミリ秒弱かかるため、このアプローチはユースケースで推奨されます。

--relocatableを使用してvenvをrpmにバンドルします。 virtualenvは$ DESTDIRに作成され、最終的に/opt/companyに移動されます。

これは私の場合です。

では、生成されたパスの最終的なターゲットを事前に渡すことができるようにするのに役立ちますか？

@gaborbernatはい！

@gaborbernatでも、

ここで良い解決策が何であるかわかりません🤔私は提案を受け入れています。

このような場合の@gaborbernatの場合、標準の動作はbuilddirとprefixを区別することです。

virtualenvにはDEST_DIR引数があり、この場合は誤解を招く可能性があります。 DEST_DIRは実際のvenvの場所であり、事実上プレフィックスです（/ usr、/ usr / localなどのように）。 したがって、 virtualenv LOCATIONを文書化すると、これがより明確になるはずです。

次に、 --destdirまたは--rootオプションを追加できます。デフォルトは/です。 このようにして、virtualenvはdestdir （chrootのようなもの）で分離して動作できます。 Python、pip、その他のスクリプトがこれにどのように対処する必要があるのか​​わかりません。

問題は、生成されたすべてのコンソールスクリプトが、shebangの作成中にパスをハードコードすることです。 シバンを含むこれらの生成されたコンソールスクリプトを、ビルド中とデプロイ後の実行中の両方で機能させる標準的な方法はありません。 それは、ビルド後に誰かがシェバンを修正しない限りです。 しかし、これは仮想環境の作成の範囲外であるため、制御できません。

@gaborbernatこれをsetuptoolsに実装する必要があるということですか？ ビルド時と実行時のターゲットロケーションの両方で分離して使用できるシバンはどれですか？

既存のvirtualenvのシバンを編集して、新しい場所で使用できるようにするvirtualenv-relocateスクリプトを作成することを考えています。 何かのようなもの ：

$ virtualenv-relocate /build/dir/venv /opt/company/app/venv
Rewriting shebang of bin/pip.
Rewriting shebang of bin/pip3.5.
...
$

setuptoolsはこれにも適しているとは思いません。 これは、ロケーションAでビルドしてから、ロケーションBにデプロイするビルドシステムの一部である必要がある機能です。

さて、Cプロジェクトでは、PATHとLD_LIBRARY_PATHを編集するだけで、分離してビルドできます。 使用するビルドシステムに関係なく。

私はCがこれをどのように達成するのかよく知らない、多分誰かがそれを説明し、それにリンクすることができるだろうか？ 以前に起こったことはここにありますhttps://github.com/pypa/virtualenv/blob/legacy/virtualenv.py#L1880-L1894 ; 基本的に、いくつかのパスを相対的なものにしようとしています。つまり、スクリプトとpth / egg-filesです。

私のリポジトリも--relocatableを使用しており、スクリプトを使用して（再配置可能な仮想環境が作成された後）、追加のライブラリをvirtualenvにコピーしています。 これにより、完全に再配置可能なvirtualenvを作成することができました。 たとえば、これをWindowsで使用し、virtualenvをインストーラーに追加します。 インストール後、python3プログラムはパッケージ化されたvirtualenvで正常に動作しています。

同じユースケースは、MacとLinuxでも機能します。

@ Gagi2kで行っていることは、現在の再配置可能な実装の脆弱性をすでに示しています。 envを作成した後、完全に再配置可能にするために、いくつかの追加のスクリプトを実行する必要がありました。 問題は、パッケージを完全に再配置可能にする方法が、ターゲット環境に大きく依存していることです。 したがって、ここでの考え方は、virtualenv自体が環境を完全に再配置可能にすることを諦め（多くの場合成功できないため）、代わりに、これを実現するこのカスタムスクリプトを作成する人々に完全にジョブを委任するというものです。 ターゲット環境の知識を持っているスクリプトなので、何かを再配置可能にするために必要な変更の内容と量を正確に把握してください。

本当の、公正な点。

私の問題は多かれ少なかれ、以前に提供した機能を再作成し、すべてのプラットフォームといくつかのディストリビューションでテストして、古い機能とまったく同じようにする必要があることです。

私または他の誰かがこれを実装する時間があるまで、私は今のところ古いvirtualenvバージョンに固執しようと思うと思います。

@ Gagi2kは、 virtualenv-relocateプロジェクトのアイデアに関する上記の私のコメントを参照してください。 私はこれについて他の人と協力して喜んでいます。 https://github.com/spotify/dh-virtualenv/が出発点として適している場合があります。

@bersace thx、私はすでに古いコードをコピーし、

@ Gagi2k共有して

@bersaceまだ進行中です： https ： //codereview.qt-project.org/c/qt/qtivi/+/290859

virtualenv 20の更新全体により、予想よりもはるかに多くの問題が発生します。 古い機能を再利用してスクリプトを再配置可能にすることは大したことではありませんが、現在はvenvに基づいており、そのpyvenv.cfgを使用すると、はるかに複雑になります。 たとえば、Windowsでは、古いvirtualenvが多くのベースpyファイルをコピーしました/ lib / python（またはそれをシンボリックリンクしました）。 現在、それらはまったくコピーされていませんが、pyvenvは元の場所を指しているだけです。 元の場所が更新されたら、virtualenvがそれを処理する必要があり、必要なすべてがまだ適切に配置されていることを期待する必要があります。 さらに大きな問題はhttps://bugs.python.org/issue39469です。これにより、virtualenvを再配置可能にするためにすべてをセットアップする相対的な場所を渡すことが困難になります...

今のところ、私はそれができるとは思いません（pyvenv.cfgがそれをサポートしていなければ）。

@gaborbernat virtualenvを本来の意図と誤用している可能性がありますが、pipを使用して拡張できるようにするために、アプリケーションに独自のpython3コピーを提供する公式の方法は何ですか？

@ Gagi2k私はここで何かが欠けていると確信しています。 しかし、特定のマシンのインストールフェーズの一部としてpyenv.cfg honeを変更するだけではいけませんか？

@gaborbernat virtualenvを本来の意図と誤用している可能性がありますが、pipを使用して拡張できるようにするために、アプリケーションに独自のpython3コピーを提供する公式の方法は何ですか？

仮想環境は、常にマシン上のPythonインタープリターを参照するように設計されています。 基本的な前提は、マシン上に完全に機能するPython環境があり、そのために複数の個別のsite-packages必要なことです。 リンクを完全に明示的にしないことにはある程度の価値がありますが（完全に明示的なパスの場合のように）、たどる場合は、 pexを使用してコードをパッケージ化してください。参照を簡単に壊すことなく、Python実行可能ファイルを事前に実行できますか？

@gaborbernat確かに、それはうまくいくでしょう、最大の問題は、ほとんどのユーザーがインストール後にフォルダの名前を変更するだけで使用でき、それが機能し続けることです...
しかし、PYTHONHOMEを設定してもうまくいくことがわかりました。少なくとも、元のインストールを参照せずに動作させたWindowsでは。

pexは面白そうだし、それをもっと詳しく見ていきます。ヒントはthxです。

@gaborbernatそれでも、

@gaborbernat確かに、それはうまくいくでしょう、最大の問題は、ほとんどのユーザーがインストール後にフォルダの名前を変更するだけで使用でき、それが機能し続けることです...

彼らがこれを期待する理由がわかりません。 これは決してそうではありませんでした。 再配置可能フラグがあっても、考えられるケースのサブセットでは当てはまりました。 したがって、なぜそれがv20で悩まされたのか。

@gaborbernatそれでも、

@bersaceこれは多くのユースケースに依存します。 deb / rpmは、Pythonがターゲットマシンの同じ場所で利用できることを保証しますか？ もしそうなら、インストール中にシェバンパスを修正するだけです👍

システムpythonに依存する@gaborbernatは、pythonが特定の場所にあることを確認するのに十分です。

postinstでインストールされたファイルを変更することは非常に悪い考えです。 これには、dpkgレルムからすべてのスクリプトを除外する必要があるため、dpkgはアップグレード時にそれらに触れません。 それは受け入れられません。

AFIAK、最善の解決策は、すべてのシバンを編集してdestdirを削除し、最終パッケージをアーカイブする前に実行するvirtualenv-change-prefixです。

@bersaceとあなたはshebangsを何に設定しますか？

@gaborbernat絶対ターゲット位置。 例： #!/opt/company/app/venv/bin/python 。

これは、そのパッケージを/以外の新しいrefrootにデプロイすることがサポートされなくなったことを意味しますか？

@gaborbernatはい、設計によるものです。 dpkg / rpmで管理されているファイルは、ユーザーが移動してはなりません。

これはrelocatableとは多少異なります。 目的は、venvを相対的なものにすることではなく、builddir（debian / build / ...または％builddir）とrundir（/）を区別することです。

私たちの側に実用的なアイテムがないので、これを閉じます。 ここで、またはvirtualenvの上でこれに取り組むことを試みる潜在的なプロジェクトについて議論を続けることをお勧めします。

実際には、バージョン管理を行わずに、ベンダーの依存関係をいくらか代替することもできます。

私の場合、分散Sparkクラスターでのプログラムの実行をサポートするために、必要な依存関係を含むpythonパッケージを圧縮し、それを「アーカイブ」としてSpark onYarnに渡す必要があります。 この操作はアナコンダで完了できますが、私の会社ではエンタープライズソフトウェアを使用できません。 relocatableは、以前はこの問題を解決できましたが、現在はなくなりました。

私の場合、分散Sparkクラスターでのプログラムの実行をサポートするために、必要な依存関係を含むpythonパッケージを圧縮し、それを「アーカイブ」としてSpark onYarnに渡す必要があります。 この操作はアナコンダで完了できますが、私の会社ではエンタープライズソフトウェアを使用できません。 relocatableは、以前はこの問題を解決できましたが、現在はなくなりました。

こんにちは@jackhhh 、既存のユースケースの回避策を見つけましたか？
同じ問題が発生しています。