23

Pythonのvirtualenvと同等またはそれに近い機能はありますが、Perlの場合はどうでしょうか。

私はPythonでいくつかの開発を行いましたが、システム以外のバージョンのモジュールを、混乱を引き起こすことなく別の環境にインストールできる可能性は大きな利点です。今、私はPerlで新しいプロジェクトに取り組む必要があり、virtualenvのようなものを探していますが、Perl用です。Pythonのvirtualenvに相当するPerlまたは代替品を提案できますか？

Y個の異なるアプリケーションをデプロイするためにX個の非システムPerlパッケージのセットをセットアップしようとしています。さらに悪いことに、これらのアプリケーションは同じパッケージの異なるバージョンを必要とする可能性があるため、それぞれを別々のモジュール/ライブラリ環境にインストールする必要がある場合があります。X <Y <3の場合は手動でこれを行うことができますが、10>Y>Xの場合は手動で行うべきではありません。

理想的には、私が探しているものは次のように機能するはずです。

perl virtualenv.pl my_environment
. my_environment/bin/activate
wget http://.../foo-0.1.tar.gz
tar -xzf foo-0.1.tar.gz ; cd foo-0.1
perl Makefile.pl
make install # <-- package foo-0.1 gets installed inside my_environment
perl -MCPAN -e 'install Bar' # <-- now package Bar with all its deps gets installed inside my_environment
4

8 に答える 8

21

local::libのように、すべての作業をまとめてくれるというツールがありますvirtualenv。そうなる：

  • @INCそれが使用されるプロセスで設定します。
  • PERL5LIB子プロセスの設定など。
  • MakeMaker適切な変数を設定して、CPAN、、、Module::Buildなどにライブラリをインストールし、構成をローカル ディレクトリに保存するよう説得します。
  • PATHインストールされたバイナリが見つかるように設定します。
  • コマンドラインから使用するときに環境変数を stdout に出力して、変数を入力してからほとんど忘れることができるようにeval $(perl -Mlocal::lib) します。.profile
于 2009-09-14T21:12:15.927 に答える
2

私はschrootこの目的のために使用しました。これは virtualenv よりも少し重いですが、漏れてはならないことは何もないと確信できます。

Schrootchroot 環境を管理しますが、ホーム ディレクトリを chroot にマウントするので、chroot のバイナリとライブラリを使用するだけで、通常のシェル セッションのように見えます。

私はそれがdebian/ubuntuだけかもしれないと思います。

をセットアップするとschroot、上記のスクリプトは次のようになります。

schroot -c my_perl_dev
wget ...

これに関する興味深い記事については、http://www.debian-administration.org/articles/566を参照してください。

于 2009-09-15T12:16:37.437 に答える
2

調査中に、このページと他のいくつかのページを発見しました (これは古すぎて新しいテクノロジーが欠けています。

perlbrew と plenv の問題は、それらが virtualenv ではなく pyenv の代わりに見えることです。ここで述べたように、pyenv は python バージョンを管理するためのもので、virtualenv はプロジェクトごとのモジュール バージョンを管理するためのものです。そのため、はい、いくつかの点でlocal::libに似ていますが、より使いやすくなっています。

この質問に対する適切な答えはまだ見たことがありませんが、私が読んだことから、最善の解決策は次のようなものであるように見えます:

  • Perl バージョン管理: plenv / perlbrew (私が見る限り、ほとんどの人は perl ベースの perlbrew よりも、より現代的な bash ベースの plenv を好みます)
  • モジュールのバージョン管理:カートン
  • モジュールのインストール: cpan (とにかく cpanminus、 ymmv )

正直なところ、これは理想的な設定ではありませんが、私はまだ学習中なので、まだ優れているかもしれません. 気分が悪いだけです。それは確かにvirtualenvのようなものではありません。

「それ は 可能です」と言っている投稿がいくつか見つかりましたが、どちらもそれ以上進んでいません。

于 2016-04-20T04:23:11.550 に答える
1

Makefile.PL の INSTALL_BASE 構成 (または Build.PL の --install_base オプション) を使用する必要があるように見えますか? ソリューションがあなたのために何をする必要がありますか？インストールされたモジュールを適切な場所に配置するだけでよいようです。私たちにあなたの仕事を手伝わせるのではなく、解決策であるとあなたが考えるものを指定することによって、問題をXY問題として提示しました。

自分のモジュール/ライブラリ ディレクトリを保持するにはどうすればよいですか? を参照してください。たとえば perlfaq8 では。

CPAN からモジュールをダウンロードする場合、最新のcpanコマンド ( App::Cpan 内) には、-j別の CPAN.pm 構成ファイルを選択できるスイッチがあります。これらの構成ファイルでは、CPAN.pm オプションを設定して、好きな場所にインストールできます。

あなたの説明に基づいて、local::lib は単一の単純なケースで機能するように思えますが、アプリケーションごとにカスタムのプライベート CPAN をセットアップし、それらのカスタム CPAN から直接インストールする産業用強度の展開に対してこれを行います。たとえば、MyCPAN::App::DPANモジュールを参照してください。そこから、環境を分析し、各アプリケーションに適切な値を設定するカスタム CPAN.pm 構成を使用して、そのアプリケーション専用のディレクトリにすべてをインストールできます。

アプリケーションを Task:: として配布することも検討してください。他の Perl モジュールと同じようにインストールしますが、依存関係は同じ設定 (INSTALL_BASE など) を共有します。

于 2009-09-15T16:27:12.867 に答える
1

プログラムは、ライブラリ uwith をチェックするディレクトリを変更できますuse lib。この lib ディレクトリは、現在のディレクトリからの相対パスにすることができます。これらのディレクトリのライブラリは、@INC 配列の先頭に配置されるため、システム ライブラリの前に使用されます。

cpan はライブラリを特定のディレクトリにインストールすることもできると思います。確かに、cpan はインストールのためにCPAN サイトから描画するため、これは最適なオプションではない可能性があります。

于 2009-09-14T21:06:32.687 に答える
1

virtualenvこれがあなたが話していることと同じかどうかはわかりませんが@INC、マンページで特別な変数を探してくださいperlvar。

于 2009-09-14T21:11:06.337 に答える
0

私がやっていることは、CPAN シェル (cpan) を起動し、そこから独自の Perl 5.10 をインストールすることです (コマンドは install perl-5.10 だと思います)。これにより、さまざまな構成設定が要求されます。/usr/local (またはデフォルト以外のインストール場所) の下のパスを指すようにします。

次に、結果の場所を実行可能ファイルの $PATH に標準の perl の前に配置し、その CPAN シェルを使用して必要なモジュール (通常は多数) をインストールします。私のPerlスクリプトはすべて次の行で始まります

#!/usr/bin/env perl

このアプローチで問題が発生したことはありません。

于 2009-09-14T21:23:27.863 に答える