linux - mcpan - ¿Cómo manejas los módulos de Perl cuando usas un administrador de paquetes?

perl mcpan

Question

Una pregunta reciente aquí en SO me hizo pensar.

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 se actualizan sus módulos siempre 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 otros usuarios 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?

Answer 1

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

perlbrew switch $version

Answer 2

Empecé a usar Gentoo recientemente y Gentoo tiene algunas ventajas muy importantes en esta área. La primera 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.

Por lo general, en Gentoo, mi enfoque es usar g-cpan para crear un archivo ebuild, luego instalar desde allí, ajustando 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 tiene y el paquete de gentoo es muy fácil de todos modos /

Answer 3

Estoy usando Debian para desarrollo y producción, y confío en los paquetes Perl 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 e 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 la copia de respaldo de 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 brindan un mantenimiento sencillo, especialmente para los servidores implementados, ya que sabe exactamente qué paquetes están instalados, y una sencilla apt-get update;apt-get upgrade (desde debian o desde un repositorio local) actualiza todos los servidores al mismo estado, incluidos los módulos de Perl.

Answer 4

Hago lo siguiente en todos mis cuadros:

• Recopilo 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 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.

Answer 5

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 programáticamente (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.

Answer 6

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.

Dado que 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 en particular, solo uso la que quiero:

$ perl5.10.0 program.pl

El binario particular asegura que el programa escoja la ruta correcta de búsqueda del módulo y demás (es lo mismo en el módulo Config.pm para ese binario).

Aquí hay un script que uso 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 de Effective Perler:

• Haga enlaces a herramientas por versión.
• Administre sus módulos de Perl con Git.

Answer 7

Para la producción:

En desarrollo, elija una versión del módulo perl que parezca adecuada 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 compilació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 de Perl NO se actualizan por ningún proceso que no siga este modelo. Tampoco lo es ningún otro software de producción.

Answer 8

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 hogar, (.perl) sin necesidad de iniciar sesión.

Answer 9

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

No debería necesitar una Tarea :: para cada proyecto. Solo use Module :: Install (me gusta usar Module :: Starter así:

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

y luego solo abre sus dependencias requiere ''module :: dependency''; en el Makefile.PL. Finalmente, cuando es el tiempo de instalación, simplemente haces un perl Makefile.PL (responde sí) y luego make installdeps

[Editar 5 años después de cuando di esta respuesta originalmente]

En 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.

Answer 10

Uso puertos de FreeBSD y cierro todas las dependencias de CPAN en un "meta puerto" como una especie de puerto local . FreeBSD tiene una cantidad bastante grande de módulos CPAN y su sistema de compilación es lo suficientemente accesible como para que pueda escribir fácilmente su propio puerto si no existe, simplemente no olvide enviar dicho puerto 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, de nuevo no olvide enviar el cambio :-).

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.

En pocas palabras: una vez que supere su fobia de edición de Makefiles, los puertos de FreeBSD son una excelente manera de mantener su aplicación Perl y sus dependencias.