2017-10-16 47 views
6

Nie mogę znaleźć wiarygodnego/wyczerpującego opisu miejsca, w którym CPAN instaluje swoje pliki. Zakładam, że musi istnieć zestaw reguł i że nie jest to tak proste jak "katalog XYZ", ponieważ na przykład wielu użytkowników na Linuksie może uruchamiać CPAN, mimo że istnieje jedna instalacja Perla i nadal działa. Więc jakie są te zasady?Gdzie CPAN instaluje moduły?

Druga część tego pytania: Dokumentacja zmiennej środowiskowej PERL5LIB mówi, że jest to "Lista katalogów, w których należy szukać plików biblioteki Perla przed zaglądaniem do standardowej biblioteki i bieżącego katalogu."

Zakładam, że CPAN nie instaluje się w standardowej lokalizacji biblioteki, ponieważ prawdopodobnie jest ona ustalona dla konkretnej wersji Perla. Więc może CPAN instaluje się w PERL5LIB?

I wreszcie, jak już wspomniałem, jak CPAN radzi sobie z faktem, że wielu użytkowników może korzystać z tej samej instalacji Perla? Przepraszam, jeśli to jest osobne pytanie, ale wydaje się prawdopodobnie powiązane.

Odpowiedz

5

Perl określa trzy zestawy lokalizacji instalacji.

  • perl, dla modułów zawartych w samym Perlu.
  • vendor, dla modułów instalowanych przez dostawcę pliku binarnego perl.
  • site, dla modułów instalowanych przy użyciu cpan.

Każdy z tych zestawów zapewnia miejsca instalacji dla wielu typów plików.

     Installation location 
         -------------------------------------------------------- 
Type of file   perl    vendor     site 
---------------------- --------------- --------------------- ------------------- 
Build-specific modules installarchlib installvendorarch  installsitearch 
Modules     installprivlib installvendorlib  installsitelib 
Binary programs   installbin  installvendorbin  installsitebin 
Other programs   installscript installvendorscript installsitescript 
man pages for scripts installman1dir installvendorman1dir installsiteman1dir 
man pages for modules installman3dir installvendorman3dir installsiteman3dir 
html docs for scripts installhtml1dir installvendorhtml1dir installsitehtml1dir 
html docs for modules installhtml3dir installvendorhtml3dir installsitehtml3dir 

można uzyskać ścieżkę dla każdego z tych miejsc przy użyciu następujących:

perl -V:{var} 

można uzyskać wszystkie ścieżki dla tych miejsc przy użyciu następujących:

perl -V:'install.*' 

Są domyślne użycie przez instalatorów [1]. Jednak dwa najczęściej używane instalatory pozwalają użytkownikowi na instalację w celu nadpisania dowolnego z nich. Jeśli moduł jest zainstalowany w niestandardowej lokalizacji, można użyć PERL5LIB, aby perl wiedział, gdzie znaleźć moduł.


  1. CPAN nie instalować modułów. To jest repozytorium.

    nie instaluje modułów. cpan pobierz dystrybucje z CPAN i uruchamia instalator dostarczony w ramach, Makefile.PL i Build.PL. (To samo dotyczy cpanm i cpanp).

    te skrypty Najczęściej ExtUtils::MakeMaker lub Module::Build zainstalować sobie (choć istnieją inne instalatorzy).

+0

Oprócz CPAN-repozytorium istnieje również moduł CPAN-the-Perl (który jest używany przez komendę 'cpan'). – melpomene

+0

Czy stół jest skądś pochodził, czy sam to napisał? – simbabque

2

CPAN tak naprawdę nie instaluje plików. Uruchomi skrypt instalacyjny osadzony w każdej dystrybucji, która następnie wykona właściwą instalację.

Dla rozkładów korzystających ExtUtils::MakeMaker, domyślnie są udokumentowane tutaj: https://metacpan.org/pod/ExtUtils::MakeMaker#make-install (a domyślna wartość INSTALLDIRS jest site). Dla Module::Build, patrz https://metacpan.org/pod/Module::Build#INSTALL-PATHS.

Gdy dokumentacja mówi o $Config{foo} lub %Config, oznacza to zmienną %Config dostarczoną przez the Config module. Wartość $Config{foo} można również sprawdzić, uruchamiając perl -V:foo.

(Jeśli sądzisz, że to wydaje się niepotrzebnie skomplikowane, masz rację.)

Krótka wersja jest taka, że ​​Perl ma wiele katalogów „System”, z których jeden jest na „miejscu specyficzny” modułów, a zatem stosowany jako domyślny cel instalacji. Masz rację, że jest to pojedynczy katalog (perl install), który nie jest kompatybilny z systemem dla wielu użytkowników: jest wspólny dla wszystkich użytkowników, i potrzebujesz uprawnień root'a do instalacji modułów (i może to spowodować uaktualnienie/nadpisuj moduły z pakietów systemowych, co jest złym pomysłem).

To, co ludzie robią, to konfigurowanie ExtUtils :: MakeMaker, Module :: Build, itp. W celu zainstalowania w katalogu domowym użytkownika. Można to zrobić za pomocą zmiennych środowiskowych. Następnie powiedz perlowi, aby dodać ten katalog do @INC, aby moduły faktycznie mogły zostać znalezione i załadowane. Odbywa się to za pomocą innej zmiennej środowiskowej, PERL5LIB. (PERL5LIB nie ma wpływu na instalację, jest używany wyłącznie do ładowania.)

Wszystkie powyższe elementy są zautomatyzowane i zamknięte w local::lib. (. Lokalny :: lib może być również stosowany do np utworzyć podkatalog per-projekt modułu)

Dokumentacja CPAN mówi:

Od CPAN 1.9463, jeśli nie masz uprawnień do pisania domyślne katalogi biblioteki perl, proces konfiguracji CPAN zapyta cię, czy chcesz bootstrapować local::lib, co czyni utrzymanie osobistego katalogu biblioteki perl łatwym.


można ominąć cały problem instalując prywatną Perl w katalogu domowym (w tym przypadku katalog „system” jest tylko kolejnym podkatalogu pod $HOME a tym samym nie są nikomu udostępniane i może być napisanym przez ciebie). Jest to bardzo łatwe z np. perlbrew.


Kolejna uwaga: Właśnie znalazłeś błąd w dokumentacji dla PERL5LIB. "i bieżący katalog" jest nieaktualny: . został usunięty z domyślnej listy lokalizacji modułów ze względów bezpieczeństwa.

+0

Dzięki, to jest pomocne. W związku z tym: "Zamiast tego ludzie powinni skonfigurować ExtUtils :: MakeMaker, Module :: Build, itp., Aby zainstalować w katalogu domowym użytkownika" Czy local :: lib czyni to zbędnym? – Stephen

+0

@ Stephen Cóż, większość ludzi korzysta z local :: lib, aby to zrobić. :-) local :: lib jest w swej istocie tylko zautomatyzowanym sposobem tworzenia niektórych katalogów i prawidłowego ustawiania garści zmiennych środowiskowych. A więc tak: jeśli używasz local :: lib (dodając magiczną linię do '.bashrc' lub odpowiednika), nie musisz konfigurować czegokolwiek innego ręcznie. – melpomene

1

To złożone pytanie. Można powiedzieć, gdzie rdzeniowe biblioteki znajdują się szukając miejsce jednego z nich:

perldoc -l B 

powie Ci, gdzie moduł B rdzeń znajduje. I możesz wypróbować inne z różnymi wynikami ...

Ponadto, perl -V powie Ci wszystkie zmienne powłoki, które mają znaczenie, wraz z wartością @INC, miejsca, w których będzie szukać bibliotek.

Biblioteki rdzeniowe są zwykle spotykane w różnych miejscach niż lokalnych bibliotek. Ponadto, jeśli używasz perlbrew i local::lib możesz mieć więcej rzeczy do rozważenia. Jeśli chodzi o zmienne powłoki, wraz z PERL5LIB, masz również PERL_LOCAL_LIB_ROOT.

Jeśli chodzi o inne pytanie, powiedziałbym, że root może instalować biblioteki w całym systemie. Każdy użytkownik będzie miał te, a następnie dowolne lokalne miejsca, za pomocą zmiennych powłoki lub innych środków, takich jak opcje linii poleceń perl -I <lib location>, lub w kodzie takim jak use lib <lib location>;.

Istnieje również perlbrew że wraz z local::lib pozwala non-uprzywilejowany użytkownik zainstalować Perl i bibliotek w katalogach lokalnych.

Odnośnie sposobów instalowania modułów z CPAN, moim ulubionym jest cpanminus. Jest wywoływany przez cpanm <library to install>. Nigdy nie zawiedzie ...