2008-12-29 8 views
29

A recent question aquí en SO me hizo pensar.¿Cómo maneja usted los módulos de Perl cuando usa un administrador de paquetes?

En la mayoría de las distribuciones de Linux que probé, algunos módulos de Perl estarían disponibles a través del administrador de paquetes. Otros, por supuesto, no. Por bastante tiempo usaba mi administrador de paquetes cada vez que necesitaba instalar algún módulo de CPAN para averiguar si un paquete estaba disponible o no y para instalarlo cuando estaba.

La ventaja obvia es que puede actualizar sus módulos cada vez que esté disponible una nueva versión del paquete.

Sin embargo, se mete en problemas cuando el módulo no está disponible en forma preempaquetada y existen dependencias para ese módulo. Encender el gestor de paquetes cada vez que el shell cpan pregunta si debería seguir una dependencia puede ser bastante agotador.

A menudo, otro inconveniente es la versión del módulo preempaquetado. Si está ejecutando Debian o Ubuntu, pronto descubrirá que no podrá vivir a la vanguardia, como muchos autores de módulos de CPAN parecen hacer.

¿Cómo manejan ese problema otras personas de Perl en Linux? ¿Simplemente ignoras lo que tus gerentes de paquetes tienen para ofrecer? ¿Hay alguna herramienta que haga que apt (por ejemplo) y cpan sean mejores compañeros de equipo? ¿O simplemente no instala nada a través de la carcasa de cpan?

+0

He cambiado el título de "¿Cómo manejas los módulos de Perl en Linux?" a "¿Cómo gestionas TU módulos Perl cuando utilizas un administrador de paquetes?", ya que esto es relevante en cualquier sistema en el que se haya usado un administrador de paquetes para instalar Perl, no estrictamente Linux, por ejemplo, la distribución de macports (http://macports.org) para OSX. – Ether

Respuesta

7

Dado que esta pregunta se realizó originalmente, se ha lanzado perlbrew. Hace que la instalación de instalaciones personalizadas e independientes de perl sea trivial. Y el cambio entre esas versiones es igual de fácil:

perlbrew switch $version 
+0

¿Puede ampliar esto y cómo usarlo? Quiero decir, ¿puedes nombrar tu instalación como, 'perlbrew switch mytest1'? – not2qubit

12

Instalamos todo a través del shell CPAN. Esto ignora lo que los gestores de paquetes tienen para ofrecer, pero evita los dolores de cabeza que menciona al tratar de trabajar con ellos (activar dependencias, utilizando las versiones correctas).

Además, significa que nuestros paquetes se pueden construir de forma programática (o manualmente a través del shell) en cualquier plataforma donde se ejecute CPAN. Tener una dependencia de un administrador de paquetes afectaría su capacidad para distribuir su software a plataformas que no usan/admiten ese administrador de paquetes.

+0

¿Hay una manera automática, después de haber instalado las actualizaciones del sistema operativo que cambian su versión de Perl de, digamos, 5.6.1 a 5.6.2, para actualizar todos los módulos instalados de CPAN? –

+1

Oh, no importa, veo en las respuestas a esa otra pregunta que lo que Estoy buscando es una "autobundle". –

+0

Paul: Se espera que sea compatible, cualquier módulo XS compilado en 5.6.1 funcionará con 5.6.2. A menudo es compatible incluso en reversa (de 5.6.2 a 5.61, por ej.). –

0

Recomiendo usar solo cpan. Los módulos incluyen en Linux la distribución solo para cubrir la dependencia del paquete. Cuando instale Linux sin acceso a Internet con solo CD, no puede usar cpan, por lo que algunos módulos se incluyen como paquetes, pero para un desarrollador de Perl esto es malo.

También solía tener un cpan configurado para instalar módulos en mi casa, (.perl) sin necesidad de iniciar sesión.

35

Para el desarrollo, instalo mi propio Perl y dejo el sistema Perl solo. Si quiero actualizar el sistema Perl, uso el administrador de paquetes del sistema. Para mi desarrollo Perl, uso la herramienta cpan.

Como los mantengo separados, nunca debería estropear el Perl que el sistema necesita para sus tareas de mantenimiento y demás, pero no tengo que depender de las decisiones de desarrollo del sistema.

Es muy fácil instalar Perls por separado. Cuando ejecuta Configurar desde la distribución de origen, le preguntará dónde desea instalar todo. Dale cualquier camino que te guste. Tengo muchos Perls instalados en /usr/local/perls, por ejemplo, y todo para cada instalación vive por separado. Luego hago enlaces simbólicos en /usr/local/bin para ellos (por ejemplo, perl5.8.9, perl.5.10.0, perl5.10.0-threaded). Cuando quiero una versión particular, sólo tiene que utilizar la que yo quiero:

$ perl5.10.0 program.pl 

El binario particular, garantiza que el programa recoge la ruta de búsqueda de módulo de la derecha y así sucesivamente (que es lo mismo en el Config.módulo pm para ese binario).

Aquí hay un script que utilizo para crear los enlaces simbólicos. Se ve en el directorio bin, se da cuenta de la versión de Perl, y hace enlaces como cpan5.10.1 y así sucesivamente. Cada programa ya conoce el perl correcto para llamar:

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

Todo se instala en el lugar correcto para ese Perl en particular.

También he estado pensando que debería poner esos directorios Perl bajo algún tipo de control de fuente. Si agrego un módulo que no me gusta, retrocedo a una revisión anterior. Sin embargo, estoy empezando a hacer eso y no he jugado mucho con eso.

He escrito más sobre este tipo de cosas en el blog Perler efectiva:

+4

Demasiadas personas se disparan en el pie respondiendo manualmente las preguntas de configuración. Por favor, siempre recomiende los interruptores apropiados en su lugar: ./Configure -de -Dprefix =/some/path. -Donversión también es bueno. – ysth

+3

Creo que todos debería ir t a través de las preguntas al menos una vez en sus vidas. :) –

+0

¿También subdivide/usr/local/lib para tener una biblioteca de módulos por separado para cada instalación, o comparten todas las mismas bibliotecas? Seguramente esta última opción generará algunos conflictos, sin mencionar que es más complicado de configurar en Configurar. – Ether

6

Yo lo siguiente en todos mis cajas:

  • compilo mi propio perl: todavía uso 5.8. [89] en su mayoría, el stock 5.10.0 tiene una regresión de rendimiento que me golpea mucho, esperando que 5.10.1 intente de nuevo;
  • Uso (y lo recomiendo encarecidamente) el módulo local :: lib para mantener un directorio de módulos por proyecto. En este momento, ese directorio está sincronizado con todos los servidores donde está instalado el proyecto, pero estoy probando el uso de git;
  • Creo un módulo Task :: para cada proyecto, de modo que pueda instalar todas las dependencias con un solo comando.
6

Estoy usando Debian para desarrollo y producción, y confío en los paquetes de Debian de Debian que se proporcionan con la distribución.

Para los casos en que necesito un módulo Perl que no está disponible en debian, normalmente creo mi propio paquete Debian y lo instalo.

Por supuesto, este método no está exento de fallas, ya que muchos módulos Debian Perl están desactualizados (al menos en la versión estable actual de Debian - etch), y el backporting algo como Catalyst que tiene muchas dependencias no es práctico.

Sin embargo, al confiar en el administrador de paquetes del sistema operativo, conservo todas las características excelentes que facilitan el mantenimiento, especialmente para servidores implementados, ya que sabe exactamente qué paquetes están instalados, y un simple apt-get update;apt-get upgrade (de debian, o desde un repositorio local) actualiza todos los servidores al mismo estado, incluidos los módulos de Perl.

4

También uso cpan shell y local :: lib.

No necesita una Tarea :: para cada proyecto. Sólo tiene que utilizar el Módulo :: Instalar (me gusta usar el módulo de arranque :: así:

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

y luego simplemente hacer estallar sus dependencias en exige ':: módulo de dependencia'; en el Makefile.PL.Por último cuando es momento de la instalación, que acaba de perl Makefile.PL (la respuesta es sí), entonces make installdeps

[editar 5 años después de cuando me dio esta respuesta originalmente]

Estos días perlbrew y cpanm son las cosas para usar. local :: lib todavía tiene un caso de uso, pero la combinación de perlbrew y cpanm resuelve un superconjunto de esos casos. Use local :: lib cuando no esté preparado para compilar su propio perl.

+1

local :: lib secundado, es un regalo del cielo si quieres instalar paquetes localmente. No es un algoritmo dramáticamente ingenioso, es simplemente todo lo mágico conseguir que los instaladores de paquetes dejen caer sus cosas en un directorio nominado, con una función de bonificación para establecer el entorno cuando intentes correr contra él. Y ni siquiera necesita instalarlo en el sistema, también hay un mecanismo de arranque. – ijw

0

Para la producción:

En el desarrollo, elegir una versión del módulo de Perl que parece el adecuado para los requisitos; si es posible, elija la versión enviada del sistema operativo objetivo (esto hace que la mayoría de los siguientes sean superfluos); de lo contrario, elija otro. Cree un archivo de especificaciones RPM para ello. Use la máquina virtual de compilación limpia para generar el RPM de una manera reproducible (desde un archivo de especificación/origen registrado en la rama correspondiente).

Cuando se puede compilar la construcción final (después de la fusión), realice la misma compilación desde la rama de publicación, confirme los RPM generados en el repositorio de implementación. Esto se usará en la validación final y luego se lanzará a producción al copiarse en el repositorio de producción.

Todos los servidores en producción usan exactamente el mismo binario que se ha probado completamente; usan el mismo archivo de especificación y fuente que el desarrollador pretendía.

Los módulos Perl NO se actualizan por ningún proceso que no siga este modelo. Tampoco lo es ningún otro software de producción.

0

Uso los puertos de FreeBSD y cierro todas las dependencias de CPAN en un "meta puerto" como una especie de local port. FreeBSD tiene un número bastante grande de módulos de CPAN y su build system is approachable enough que puede escribir fácilmente su propio puerto si no existe, simplemente no se olvide de submit said port para que se incluya en el árbol de puertos. Si el puerto no tiene la versión actual en stock, siempre puede editar el Makefile para el puerto para que use la nueva versión, nuevamente don't forget to submit the change :-).

Por último, uso Tinderbox para construir todo el lío como paquetes binarios que luego instalo en todas las máquinas de producción y desarrollo.

Conclusión - Una vez que superas tu fobia de edición de Makefiles, los puertos de FreeBSD son una excelente manera de mantener tu aplicación Perl y sus dependencias.

0

He comenzado a usar Gentoo Gentoo recientemente y tiene algunas ventajas muy importantes en esta área. El primero es que g-cpan generalmente puede instalar muchos módulos (aunque no todos) de CPAN como paquetes Gentoo de forma nativa, aunque la actualización se convierte en un problema.

Normalmente, en Gentoo, mi enfoque es usar g-cpan para crear un archivo ebuild, luego instalar desde allí, retocando si es necesario. La ventaja es que la actualización se vuelve realmente fácil. Luego muevo el archivo desde g-cpan/perl a dev-perl y lo pongo en una superposición para que otros lo usen. Esto me permite manejar rápidamente los casos que g-cpan no necesita y el paquete de gentoo es muy fácil/

Cuestiones relacionadas