Jak zarządzać modułami Perla używając menedżera pakietów?

Dla rozwoju, instaluję własny Perl i zostawiam systemowy Perl w spokoju. Jeśli chcę uaktualnić systemowy Perl, używam menedżera pakietów systemowych. Do mojego Perla programistycznego używam narzędzia cpan.

Ponieważ trzymam je osobno, nigdy nie powinienem zepsuć Perla, którego system potrzebuje do zadań związanych z utrzymaniem itp., ale nie muszę polegać na decyzjach systemu dotyczących rozwoju.

Bardzo łatwo jest zainstalować oddzielne Perle. Po uruchomieniu Configure ze źródła Dystrybucja, zapyta cię, gdzie chcesz zainstalować wszystko. Daj mu jakąkolwiek drogę. Mam wiele Perl zainstalowanych na przykład w /usr/local / perls i wszystko dla każdej instalacji żyje osobno. Następnie wykonuję dla nich dowiązania symboliczne w /usr/local/bin (np. perl5.8.9, perl.5.10.0, perl5.10.0-gwintowane). Kiedy chcę konkretnej wersji, po prostu używam tej, którą chcę:

$ perl5.10.0 program.pl

Konkretny plik binarny zapewnia, że program wybiera właściwe wyszukiwanie modułów ścieżka i tak dalej (to te same rzeczy w Config.pm moduł do tego binarnego).

Oto skrypt, którego używam do tworzenia dowiązań symbolicznych. Wygląda w katalogu bin, oblicza wersję Perla i tworzy linki typu cpan5.10.1 i tak dalej. Każdy program zna już odpowiedni perl do wywołania:

#!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!";
    }
}

Wszystko jest instalowane we właściwym miejscu dla danego Perla.

Myślałem też, że powinienem umieścić te katalogi Perla pod jakąś kontrolą źródeł. Jeśli dodam moduł mi się nie podoba, po prostu wycofuję się do wcześniejszej rewizji. Dopiero zaczynam to robić i nie grałem z tym zbyt często.

• twórz linki do narzędzi według wersji.
• Zarządzaj swoimi modułami Perla za pomocą Git.

Instalujemy wszystko poprzez powłokę CPAN. Ignoruje to to, co menedżerowie pakietów mają do zaoferowania, ale unika bólów głowy, o których wspominasz, gdy próbujesz z nimi pracować (uruchamianie zależności, używanie poprawnych wersji).

Ponadto oznacza to, że nasze pakiety mogą być budowane programowo (lub ręcznie przez powłokę) na dowolnej platformie, na której działa CPAN. Uzależnienie od menedżera pakietów wpłynie na możliwość dystrybucji oprogramowania na platformy, które nie używają / nie obsługują ten menedżer pakietów.

Wykonuję następujące czynności na wszystkich moich pudełkach:

• kompiluję swój własny perl: nadal używam 5.8.[89] głównie, stock 5.10.0 ma regresję wydajności, która bardzo mnie uderza, czekając na 5.10.1, aby spróbować ponownie;
• używam (i zdecydowanie polecam) modułu local::lib do przechowywania katalogu modułów dla każdego projektu. W tej chwili ten katalog jest rsync'ed do wszystkich serwerów, na których jest zainstalowany projekt, ale testuję zamiast tego używając git;
• tworzę moduł Task:: dla każdego projektu, tak aby Mogę zainstalować wszystkie zależności za pomocą jednego polecenia.

Używam Debiana do rozwoju i produkcji i polegam na pakietach Debiana Perla, które są dostarczane z distro.

W przypadkach, gdy potrzebuję modułu Perla, który nie jest dostępny w Debianie, zazwyczaj tworzę swój własny pakiet Debiana i instaluję go.

Oczywiście, ta metoda nie jest bez wad, ponieważ wiele modułów Debiana Perla jest przestarzałych (przynajmniej w obecnej stabilnej wersji Debiana-etch), A backportowanie czegoś w rodzaju Catalyst , który ma wiele zależności nie jest praktyczne.

Jednakże, opierając się na menedżerze pakietów systemu operacyjnego, zachowuję wszystkie jego wspaniałe funkcje, które zapewniają łatwą konserwację, szczególnie dla wdrożonych serwerów, ponieważ dokładnie wiesz, jakie pakiety są zainstalowane, i prosty apt-get update;apt-get upgrade (z Debiana lub z lokalnego repozytorium) aktualizuje wszystkie serwery do tego samego stanu, w tym Moduły Perla.

Używam również powłoki cpan I local:: lib.

Nie powinieneś potrzebować zadania:: dla każdego projektu. Po prostu użyj Module:: Install (lubię używać Module::Starter tak:

$ module-starter --mi --module=Module::Name --author="Me" [email protected]

A następnie po prostu wrzuć swoje zależności w 'module:: dependency'; w Makefile.PL. w końcu, gdy jest czas instalacji, po prostu perl Makefile.PL (odpowiedź Tak) następnie make installdeps

[edytuj 5 lat od momentu, gdy udzieliłem pierwotnie tej odpowiedzi]

W dzisiejszych czasach perlbrew i cpanm to rzeczy, których można używać. lokalna:: lib nadal ma przypadek użycia, ale kombinacja perlbrew i cpanm rozwiązuje superset tych przypadków. Użyj local:: lib, gdy nie jesteś przygotowany do kompilacji własnego Perla.

Polecam używać tylko cpan. Moduły zawarte w dystrybucji Linuksa mają obejmować tylko zależność od pakietu. Gdy instalujesz Linuksa bez dostępu do Internetu tylko z płytami CD, nie może on używać cpan, więc niektóre moduły są dołączane jako pakiety, ale dla programisty Perla jest to złe.

Również miałem skonfigurowany cpan do instalacji modułów w moim domu, (.perl) bez potrzeby logowania roota.

Dla produkcji:

W rozwoju wybierz wersję modułu Perla, która wydaje się odpowiednia dla wymagań; jeśli to możliwe, wybierz wersję dostarczoną przez system operacyjny docelowy (to sprawia, że większość z poniższych zbędnych), w przeciwnym razie wybierz inną. Utwórz dla niego plik specyfikacji RPM. Użyj clean build VM, aby zbudować RPM w odtwarzalny sposób(ze specfile / źródła sprawdzonego w odpowiedniej gałęzi).

Gdy można zbudować ostateczny build (po scaleniu), wykonaj ten sam build z release branch, commit wygenerowanych RPMs do repozytorium wdrażania. Zostanie to wykorzystane w ostatecznej walidacji, a następnie udostępnione do produkcji przez skopiowanie do repozytorium produkcyjnego.

Wszystkie serwery produkcyjne używają dokładnie tego samego pliku binarnego, który został w pełni przetestowany; używają tego samego pliku spec i źródła, co zamierzał deweloper.

Moduły Perla nie są aktualizowane przez żaden proces, który nie podąża za tym modelem. Ani żadne inne oprogramowanie produkcyjne.

Używam portów FreeBSD i zawijam wszystkie zależności CPAN w "Meta port" jako rodzaj lokalnego portu. FreeBSD ma dość dużą liczbę modułów CPAN, a ich system budowania jest na tyle przystępny , że możesz łatwo napisać swój własny port, jeśli nie istnieje--tylko nie zapomnij przesłać wspomniany port , aby został włączony do drzewa portów. Jeśli port nie ma bieżącej wersji w magazynie, zawsze możesz edytować plik Makefile dla Portu, aby używał nowego wersja, ponownie nie zapomnij zgłosić zmiany: -).

Na koniec używam Tinderbox do budowania całego bałaganu jako pakietów binarnych, które następnie instaluję na wszystkich maszynach produkcyjnych i programistycznych.

Reasumując -- gdy już opanujesz swoją fobię edytowania plików Makefile, porty FreeBSD są świetnym sposobem na utrzymanie aplikacji Perla i jej zależności.

Zacząłem używać Gentoo niedawno i Gentoo ma kilka bardzo ważnych zalet w tej dziedzinie. Po pierwsze g-cpan jest w stanie zazwyczaj instalować wiele (choć nie wszystkie) modułów z CPAN jako Pakiety Gentoo natywnie, chociaż aktualizacja staje się problemem.

Zazwyczaj w Gentoo, moje podejście polega na użyciu g-cpan do stworzenia pliku ebuild, a następnie zainstalowaniu z niego, w razie potrzeby poprawiając. Zaletą jest to, że modernizacja staje się naprawdę łatwa. Następnie przenoszę Plik z g-cpan / perl do dev-Perla i umieścić go w nakładce, aby inni mogli go użyć. Pozwala mi to szybko obsłużyć przypadki, w których g-cpan nie ma, a gentoo packaging i tak jest bardzo proste/