Jak mogę zarządzać zależnościami modułu Perla?

Question

Jestem obecnie w projekcie, który rozwija się za pomocą ramy opracowanej przez inny dział jako bazę. Obecnie wprowadzamy standardy jakości (na koniec, yay!) W naszym dziale, ale obecnie nie jest możliwe wprowadzenie ich do innego działu. W konsekwencji pracujemy przeciwko ruchomemu celowi bez stabilności API lub stabilnych wydań, co jest stresujące.

Ponieważ staramy się naprawiać rzeczy na samym końcu, chcielibyśmy zabezpieczyć się aż do zmian w kodzie źródłowym "upstream" a.k.a. Wyobraziliśmy sobie trudne zależności modułów:

1. Używanie tylko niektórych zakresów wersji modułów ramowych, zdefiniowanych w kodzie.
2. Przy użyciu testu testu jednostkowego, aby upewnić się, że wszystkie niezbędne wersje są nadal dostępne.
3. Każde rozszerzenie zakresu wersji wymagające recenzowania kodu frameworka.

Taki jest plan. Teraz pytania:

1. Czy to rozsądne? Jeśli nie, jakieś inne pomysły?
2. Jak można to zaimplementować w perlu? Używając use Module, możemy zdefiniować tylko ten kod, z którym ma działać.

Answer 1

Chociaż mam nadzieję, że CPAN jest bardziej stabilny niż moduły, na których polegasz, pozwól, że zadam podobne pytanie: w jaki sposób zabezpieczyłbyś się przed nieoczekiwanymi zmianami w module CPAN?

Jedna odpowiedź: pobierasz moduł i regresujesz kod w środowisku testowym.

Czy to samo można tutaj zastosować? Czy musisz wskazywać "na żywo" kopie swoich modułów, czy możesz wskazać własne kopie?

Answer 2

Powiedziałbym o tym, robiąc prywatną kopię bibliotek, od której mój kod jest zależny, i umieszczając je w katalogu mojego projektu lib przy założeniu, że nigdy nie będę modyfikować tych kopii, z wyjątkiem okresowego sprawdzania nowych wersji po osiągnięciu kamieni milowych.

Answer 3

To bardzo rozsądny plan i wdrażam go za pośrednictwem prywatnego repozytorium podobnego do CPAN, które nazywam "DPAN". Wybierasz odpowiednie dystrybucje i wersje z rzeczywistego CPAN (lub BackPAN) i tworzysz z niego własne repozytorium. Twoi klienci CPAN wskazują tylko w tym repozytorium, skutecznie zamrajając wersje dokładnie tak, jak chcesz. Ulepszasz tylko kiedy chcesz.

Dodatkowo, DPAN pozwala łatwo dodawać nie tylko swój lokalny, prywatny kod, ale także modyfikować pakiety stron trzecich w celu naprawienia problemów z ich instalacjami itp. Mam pełne uzasadnienie dla tego pomysłu w wydaniu Lato 2009 z The Perl Review. Możesz także zobaczyć moje slajdy z mojej rozmowy Creating Your Own CPAN na YAPC :: Rosja.

Jeśli interesuje Cię takie rozwiązanie, sprawdź mój moduł MyCPAN::App::DPAN. Zajmuje się katalogiem dystrybucji i robi resztę za ciebie. Wskazujesz na nim swojego klienta CPAN (i upewniasz się, że nie będzie on łączył się z Internetem) i tyle.

Po utworzeniu własnego repozytorium można z łatwością utworzyć repozytorium testowe.Zrzuć wersje, które chcesz zaktualizować, zainstaluj kod na serwerze testowym i zbieraj wyniki. Jeśli nie podoba ci się wyniki, możesz łatwo zmienić repozytorium.

Następnym ważnym krokiem w mojej pracy z DPAN jest wzięcie istniejącej instalacji Perla wraz z dowolnymi modułami, które zainstalowałeś, i utworzenie repozytorium, które zapewni ci ten stan instalacji. Mam wszystkie główne elementy potrzebne do wykonania pracy, ale byłem trochę zajęty, aby kilku klientów działało z pierwszymi bitami.

Jeśli chcesz dowiedzieć się więcej na ten temat, daj mi znać. :)

Answer 4

Spójrz na PAR. Umożliwia spakowanie zestawu zależności w jeden plik. Możesz wziąć wydane moduły, wrzucić je do pliku PAR i zaktualizować plik PAR tylko wtedy, gdy chcesz zaakceptować ich zmiany.

Answer 5

Jeśli chcesz sprawdzić wersję modułów zewnętrznych, można (przynajmniej jeśli oni zgłaszać swoje $ version poprawnie) użyć czegoś takiego:

BEGIN { 
    use foo; 
    use bar; 

    die "Ghaaaa" if $foo::VERSION < 2.1; 
    die "Aaaargh" if $foo::VERSION > 3.12; 
} 

Answer 6

Ktoś wskazał PAR już. Pozwolę sobie wspomnieć o PAR::Repository i jego module towarzyszącym PAR::Repository::Client. Implementują infrastrukturę klient/serwer, która może automatycznie ładować wszelkie zależności, które nie są lokalnie zlokalizowane (lub które mogą nawet preferować pakiety serwera). Jako administrator możesz po prostu dodawać lub usuwać pakiety do lub z repozytorium. Faktyczne podawanie pakietów odbywa się na całkowicie normalnych serwerach: Dowolny serwer http (s) lub po prostu plik: //. Inne protokoły powinny być raczej proste do wdrożenia.

Posiada wspomniany wyżej magiczny mechanizm automatycznego ładowania, instalację pakietu i automatyczną aktualizację pakietu. Oprócz dokumentacji modułu, możesz rzucić okiem na presentation on PAR from YAPC::Europe 2008, który obejmuje to w pewnym zakresie.

Muszę przyznać, że automatyczna modernizacja jest wystarczająco zaawansowaną technologią, która może jeść dziecko lub dwoje, jeśli ma wszystko z kociaków.

Answer 7

Cóż, myślę, że Carton jest czymś, czego szukasz (bundler dla perla). W połączeniu z plenv wierzę, że to wystarczy.