32

ここSOに関する最近の質問で私は考えました。

私が試したほとんどのLinuxディストリビューションでは、一部のPerlモジュールはパッケージマネージャーから入手できます。もちろん、他の人はそうではありません。かなり長い間、CPANモジュールをインストールしてパッケージが利用可能かどうかを確認し、利用可能になったときにインストールする必要があるときはいつでも、パッケージマネージャーを使用していました。

明らかな利点は、パッケージの新しいバージョンが利用可能になるたびにモジュールを更新できることです。

ただし、モジュールが事前にパッケージ化された形式で利用できず、そのモジュールに依存関係がある場合は、問題が発生します。cpanシェルが依存関係に従うべきかどうかを尋ねるたびにパッケージマネージャーを起動するのは非常に面倒です。

多くの場合、別の欠点は、事前にパッケージ化されたモジュールのバージョンです。DebianまたはUbuntuを実行している場合、多くのCPANモジュールの作成者が行っているように、最先端に住むことができないことにすぐに気付くでしょう。

Linux上の他のPerlの人々はその問題をどのように処理しますか?パッケージマネージャーが提供するものを無視しますか?apt(たとえば)とcpanをより良いチームメイトにするツールはありますか?それとも、cpanシェルを介して何もインストールしないのですか?

4

10 に答える 10

35

開発のために、私は独自の Perl をインストールし、システムの Perl はそのままにしておきます。システム Perl をアップグレードする場合は、システム パッケージ マネージャーを使用します。Perl の開発では、cpan ツールを使用します。

私はそれらを別々に保管しているので、システムが保守タスクなどに必要とする Perl を台無しにすることは決してありませんが、開発のためにシステムの決定に依存する必要はありません。

個別の Perl をインストールするのは非常に簡単です。ソース ディストリビューションから Configure を実行すると、すべてをインストールする場所を尋ねられます。任意のパスを指定してください。たとえば、/usr/local/perlsに多くの Perl がインストールされており、各インストールのすべてが個別に存在します。次に、それらのシンボリック リンクを/usr/local/binに作成します (たとえば、perl5.8.9、perl.5.10.0、perl5.10.0 スレッド)。特定のバージョンが必要な場合は、必要なバージョンを使用します。

$ perl5.10.0 program.pl

特定のバイナリは、プログラムが正しいモジュール検索パスなどを取得することを保証します (これは、そのバイナリの Config.pm モジュールと同じものです)。

シンボリックリンクを作成するために使用するスクリプトを次に示します。bin ディレクトリを調べて、Perl のバージョンを割り出し、のようなリンクを作成cpan5.10.1します。各プログラムは、呼び出す適切な perl を既に認識しています。

#!perl

use 5.010;

use strict;
use warnings;

use File::Basename;
use File::Spec::Functions;

my $perls_directory = catfile(
    $ARGV[0] // '/usr/local/perls', 
    'perl*'
);
die "$perls_directory does not exist!\n" 
    unless -d dirname $perls_directory;

my $links_directory = $ARGV[1] // catfile( $ENV{HOME}, 'bin' ); #/
die "$links_directory does not exist!\n" unless -d $links_directory;

foreach my $directory ( glob( $perls_directory ) )
{
    say "Processing $directory...";

    unless( -e catfile( $directory, 'bin' ) )
    {
        say "\tNo bin/ directory. Skipping!";
        next;
    }

    my @perls = glob( catfile( $directory, qw( bin perl5* ) ) );    

    my( $perl_version ) = $perls[0] =~ m/(5\.\d+\.\d+)\z/;
    say "\tperl version is $perl_version";

    foreach my $bin ( glob( catfile( $directory, 'bin', '*' ) ) )
    {
        say "\tFound $bin";
        my $basename = basename( $bin );

        my $link_basename = do {
            if( $basename =~ m/5\.\d+\.\d+\z/) { $basename }
            else                               { "$basename$perl_version" }
        };

        my $link = catfile( $links_directory, $link_basename );
        next if -e $link;
        say "\t\tlinking $bin => $link";
        symlink $bin => $link or
            warn "\t\tCould not create symlink [$!]: $bin => $link!";
    }
}

その特定の Perl の適切な場所にすべてがインストールされます。

また、これらの Perl ディレクトリを何らかのソース管理下に置くべきだとも考えていました。気に入らないモジュールを追加すると、以前のリビジョンに戻るだけです。私はそれをやり始めたばかりで、あまり遊んでいません。

この種のことについては、Effective Perler ブログで詳しく書いています。

于 2008-12-29T19:23:13.820 に答える
12

CPANシェルを介してすべてをインストールします。これは、パッケージマネージャーが提供するものを無視しますが、パッケージマネージャーを操作しようとするときに言及する頭痛の種を回避します(依存関係の発火、正しいバージョンの使用)。

さらに、CPANが実行されている任意のプラットフォームで、パッケージをプログラムで(またはシェルを介して手動で)構築できることを意味します。パッケージマネージャーに依存していると、そのパッケージマネージャーを使用/サポートしていないプラットフォームにソフトウェアを配布する機能に影響します。

于 2008-12-29T18:06:23.243 に答える
9

この質問は最初に尋ねられたので、perlbrewがリリースされました。これにより、カスタムの自己完結型 perl のインストールが簡単になります。これらのバージョン間の切り替えも同様に簡単です。

perlbrew switch $version
于 2012-03-13T14:32:48.227 に答える
7

私は開発と運用にDebianを使用しており、ディストリビューションで提供される debian Perl パッケージに依存しています。

Debian で利用できない Perl モジュールが必要な場合は、通常、独自の debian パッケージを作成してインストールします。

もちろん、この方法には欠点がないわけではありません。多くの debian perl モジュールが古くなっているため (少なくとも現在の debian 安定バージョンでは - etch)、多くの依存関係を持つCatalystのようなものをバックポートすることは実用的ではありません。

ただし、OS パッケージ マネージャーに依存することで、そのすべての優れた機能を保持しています。これにより、特にデプロイされたサーバーのメンテナンスが容易になります。インストールされているパッケージが正確にわかっているため、apt-get update;apt-get upgrade(debian から、またはローカル リポジトリから)シンプルです。 ) は、Perl モジュールを含むすべてのサーバーを同じ状態にアップグレードします。

于 2008-12-30T18:59:35.600 に答える
6

すべてのボックスで次のことを行います。

  • 私は自分の perl をコンパイルします。私はまだ 5.8 を使用しています。[89] ほとんどの場合、在庫の 5.10.0 にはパフォーマンスの低下があり、5.10.1 が再試行されるのを待って、私を大いに悩ませました。
  • プロジェクトごとにモジュール ディレクトリを保持するために、local::lib モジュールを使用します (強くお勧めします)。現在、そのディレクトリは、プロジェクトがインストールされているすべてのサーバーに rsync されていますが、代わりに git を使用してテストしています。
  • 1 つのコマンドですべての依存関係をインストールできるように、プロジェクトごとに Task:: モジュールを作成します。
于 2008-12-30T01:42:36.817 に答える
4

私はcpanシェルとlocal::libも使用しています。

プロジェクトごとにTask::は必要ありません。Module :: Installを使用するだけです(私は次のようにModule :: Starterを使用するのが好きです:

$ module-starter --mi --module=Module::Name --author="Me" --email=me@cpan.org

次に、依存関係をrequires'module::dependency'にポップします。Makefile.PLにあります。最後に、インストール時になると、perl Makefile.PL(「はい」と答える)make installdeps

[私が最初にこの答えを出したときから5年後に編集]

最近はperlbrewとcpanmが使われています。local :: libにはまだユースケースがありますが、perlbrewとcpanmの組み合わせは、これらのケースのスーパーセットを解決します。独自のperlをコンパイルする準備ができていない場合は、local::libを使用してください。

于 2009-02-14T21:17:33.633 に答える
0

生産用:

開発では、要件に適していると思われるバージョンのperlモジュールを選択します。可能であれば、ターゲットOSの出荷バージョンを選択します(これにより、以下のほとんどが不要になります)。そうでない場合は、別のバージョンを選択します。そのためのRPM仕様ファイルを作成します。クリーンビルドVMを使用して、再現可能な方法でRPMをビルドします(適切なブランチにチェックインされたスペックファイル/ソースから)。

最終ビルドをビルドできる場合(マージ後)、リリースブランチから同じビルドを実行し、生成されたRPMをデプロイメントリポジトリにコミットします。これは最終検証で使用され、本番リポジトリにコピーされることで本番環境にリリースされます。

本番環境のすべてのサーバーは、完全にテストされたものとまったく同じバイナリを使用します。開発者が意図したものと同じスペックファイルとソースを使用します。

Perlモジュールは、このモデルに従わないプロセスによってアップグレードされません。他の本番ソフトウェアもありません。

于 2009-02-14T21:28:28.320 に答える
0

cpan のみを使用することをお勧めします。Linux ディストリビューションに含まれるモジュールは、パッケージの依存関係をカバーするためだけのものです。CD だけでインターネットにアクセスせずに linux をインストールする場合、cpan を使用できないため、いくつかのモジュールがパッケージとして含まれていますが、Perl 開発者にとってこれは悪いことです。

また、ルートログインを必要とせずに、自宅にモジュール(.perl)をインストールするようにcpanを構成していました。

于 2008-12-29T18:41:51.830 に答える
0

私は FreeBSD ポートを使用し、すべての CPAN 依存関係を一種のローカル ポートとして「メタ ポート」にラップします。FreeBSD には非常に多くの CPAN モジュールがあり、それらのビルド システムは親しみやすいので、独自のポートが存在しない場合でも簡単に作成できます。ポート ツリーに含まれるように、そのポートを送信することを忘れないでください。ポートに現在のバージョンの在庫がない場合は、新しいバージョンを使用するようにポートの Makefile をいつでも編集できます。変更を送信することを忘れないでください:-)。

最後に、Tinderboxを使用して混乱全体をバイナリ パッケージとしてビルドし、それをすべての運用マシンと開発マシンにインストールします。

結論 -- Makefile を編集する恐怖症を克服したら、FreeBSD のポートは、perl アプリケーションとその依存関係を維持するための優れた方法です。

于 2009-03-02T21:54:43.480 に答える