python - ¿Cómo puedo instalar entornos especializados para diferentes aplicaciones de Perl?

virtualenv (8)

Hay una herramienta llamada local::lib que envuelve todo el trabajo para usted, al igual que virtualenv . Va a:

Configure @INC en el proceso donde se usa.
Establezca PERL5LIB y otras cosas similares para procesos secundarios.
Establezca las variables correctas para convencer a CPAN, MakeMaker , Module::Build , etc. de instalar bibliotecas y almacenar configuraciones en un directorio local.
Establezca PATH para que se puedan encontrar los binarios instalados.
Imprima las variables de entorno para stdout cuando se usa desde la línea de comandos para que pueda poner eval $(perl -Mlocal::lib) en su .profile y luego olvidarse de ello.

¿Hay algo equivalente o cercano en términos de funcionalidad al virtualenv de Python, pero para Perl?

He hecho algunos desarrollos en Python y la posibilidad de tener versiones de módulos que no sean del sistema instaladas en un entorno separado sin crear ningún problema es una gran ventaja. Ahora tengo que trabajar en un nuevo proyecto en Perl, y estoy buscando algo como virtualenv, pero para Perl. ¿Puedes sugerir algún equivalente o reemplazo de Perl para virtualenv de python?

Estoy tratando de configurar X conjuntos diferentes de paquetes Perl que no sean del sistema para implementar diferentes aplicaciones Y. Peor aún, estas aplicaciones pueden requerir versiones diferentes del mismo paquete, por lo que cada una de ellas puede requerir ser instalada en un entorno de biblioteca / módulo separado. Es posible que desee hacerlo manualmente para X <Y <3. Pero no debe hacerlo manualmente para 10> Y> X.

Idealmente, lo que estoy buscando debería funcionar así:

perl virtualenv.pl my_environment . my_environment/bin/activate wget http://.../foo-0.1.tar.gz tar -xzf foo-0.1.tar.gz ; cd foo-0.1 perl Makefile.pl make install # <-- package foo-0.1 gets installed inside my_environment perl -MCPAN -e ''install Bar'' # <-- now package Bar with all its deps gets installed inside my_environment

He usado schroot para este propósito. Es un poco más pesado que virtualenv, pero puedes estar seguro de que no se filtrará nada que no debería.

Schroot gestiona un entorno chroot para usted, pero monta su directorio de inicio en el chroot para que parezca una sesión de shell normal, simplemente usando los binarios y las bibliotecas en el chroot.

Creo que puede ser debian / ubuntu solamente.

Después de configurar el schroot , su script anterior se vería como

schroot -c my_perl_dev wget ...

Vea http://www.debian-administration.org/articles/566 para un artículo interesante al respecto

Lo que hago es iniciar el shell CPAN (cpan) e instalar mi propio Perl 5.10 (creo que el comando es instalar perl-5.10). Esto pedirá varias configuraciones de configuración; Me aseguro de hacer que apunte a las rutas en / usr / local (o en alguna otra ubicación de instalación que no sea la predeterminada).

Luego pongo su ubicación resultante en mi $ PATH ejecutable antes del perl estándar, y uso su shell CPAN para instalar los módulos que necesito (generalmente, mucho). Mis scripts de Perl comienzan todos con la línea

#!/usr/bin/env perl

Nunca tuve un problema con este enfoque.

Los programas pueden modificar qué directorios verifican para bibliotecas uwith use lib . Este directorio lib puede ser relativo al directorio actual. Las bibliotecas de estos directorios se usarán antes que las bibliotecas del sistema, ya que se ubican al comienzo de la matriz @INC.

Creo que cpan también puede instalar bibliotecas en directorios específicos. Por supuesto, cpan extrae del sitio de CPAN para instalar cosas, por lo que esta puede no ser la mejor opción.

Mientras investigaba, descubrí esto y algunas otras páginas ( esta es demasiado vieja y echa de menos las nuevas tecnologías, esta publicación de reddit es un ligero error de dirección ).

El problema con perlbrew y plenv es que parecen ser reemplazos para pyenv, no virtualenv. Como se señala aquí, pyenv es para administrar versiones de Python, virtualenv es para administrar versiones de módulos por proyecto. Entonces, sí, de alguna manera similar a local :: lib , pero con una mejor usabilidad.

Todavía no he visto una respuesta adecuada a esta pregunta, pero por lo que he leído, parece que la mejor solución es algo así como:

Gestión de versiones de Perl: plenv / perlbrew (con la mayoría de las personas favoreciendo la sesión más completa basada en bash sobre la perlbrew basada en perl de lo que puedo ver)
Gestión de la versión del módulo: Cartón
Instalación del módulo: cpan (bueno, cpanminus de todos modos, mmm)

Para ser sincero, esta no es una configuración ideal , aunque todavía estoy aprendiendo, por lo que aún puede ser superior. Simplemente no se siente bien. Ciertamente no es como un reemplazo como virtualenv .

Hay un par de publicaciones que encontré diciendo " es posible " pero ninguna ha ido más allá.

No estoy seguro de si esto es lo mismo que esa cosa virtualenv que está hablando, pero busque la variable especial @INC en la página de perlvar .

Parece que solo necesita usar la configuración INSTALL_BASE para Makefile.PL (o la opción --install_base para Build.PL)? ¿Qué es exactamente lo que necesita la solución para usted? Parece que solo necesita obtener el módulo instalado en el lugar correcto. Ha presentado su problema como un problema XY especificando cuál cree que es la solución en lugar de dejar que lo ayudemos con su tarea.

Ver ¿Cómo guardo mi propio directorio de módulo / biblioteca? en perlfaq8, por ejemplo.

Si está descargando módulos de CPAN, el último comando de cpan (en App :: Cpan ) tiene un modificador -j para permitirle elegir archivos de configuración de CPAN.pm alternativos. En esos archivos de configuración puede configurar las opciones de CPAN.pm para instalar donde desee.

Según su aclaración, suena como que local :: lib podría funcionar para usted en casos únicos y simples, pero lo hago para implementaciones de fuerza industrial donde configuro CPAN privados y personalizados por aplicación, e instalo directamente desde esos CPAN personalizados. Ver mi módulo MyCPAN :: App :: DPAN , por ejemplo. A partir de eso, utilizo las configuraciones CPAN.pm personalizadas que analizan su entorno y establecen los valores adecuados para cada aplicación. Pueden instalar todo en un directorio solo para esa aplicación.

También podría considerar distribuir su aplicación como Tarea ::. Lo instala como cualquier otro módulo de Perl, pero las dependencias comparten la misma configuración (es decir, INSTALL_BASE).

También comprueba perl-virtualenv , esto parece ser envoltorio alrededor de local :: lib como lo sugiere Hobbs, pero crea un bin / activate y bin / deactivate para que puedas usarlo como la herramienta python.

Lo he usado con bastante éxito durante aproximadamente un mes sin darme cuenta de que no era tan normal como debería ser.

Hace que sea mucho más fácil configurar un virtualenv de trabajo para perl como local: lib le dirá qué variables necesita establecer, etc. perl-virtualenv crea un script de activación que lo hace por usted.