Foro - Perl en Español

Hola buenas, paso a comentarles la duda...

Volví al Perl v5.10.0 e instalé el par-packer v0.977 para tener todo funcionando, debido a que el script necesita del módulo AnyEvent, también lo instalé. El problema surge cuando lo empaqueto, que da el siguiente error.

comando:
pp -o C:\Perl\proyectos\modulodecambio.exe -M AnyEvent C:\Perl\proyectos\modulodecambios.pl

error :
C:\Documents and Settings\admin> C:\Perl\proyectos\modulodecambios.exe
AnyEvent: backend autodetection failed - did you properly install AnyEvent?

La opción -M indica que se debe cargar el módulo con el nombre que le sigue.

Es decir, que

-MAnyEvent

es lo mismo que si hubiéramos

use Anyevent;

en el programa. (¡Ojo! Observa que no hay espacio entre '-M' y el nombre del módulo.

Pero este módulo tiene un problema...

Él necesita saber el modelo de ejecución, para cargar uno u otro. Por ejemplo, si ve que, antes, se cargó el módulo Tk, sabe que debe cargar AnyEvent::Impl::Tk para gestionar eventos en ese modelo.

Pero en la línea de comandos no estás indicando ningún modelo. Y ese es justo el significado del error: AnyEvent no sabe qué modelo de eventos debe cargar.

Yo probaría, primero, a ejecutar pp pero sin '-MAnyevent'.

Ok, perfecto. Armé la línea de la siguiente manera...

pp -o C:\Perl\proyectos\modulodecambio.exe -M AnyEvent::condvar C:\Perl\proyectos\modulodecambios.pl

y en el script ya tenía puesto use AnyEvent;

Ahora me sale más código... sobre scandeps... pero si el único módulo que uso es AnyEvent...

C:\Perl>pp -o C:\Perl\proyectos\modulodecambio.exe -M AnyEvent::condvar C
:\Perl\proyectos\modulodecambios.pl
Set up gcc environment - 3.4.5 (mingw special)
Use of uninitialized value $path in pattern match (m//) at C:/Perl/site/lib/Modu
le/ScanDeps.pm line 530.
Use of uninitialized value $input_file in pattern match (m//) at C:/Perl/site/li
b/Module/ScanDeps.pm line 576.
Use of uninitialized value $name in pattern match (m//) at C:/Perl/site/lib/Modu
le/ScanDeps.pm line 1352.
Use of uninitialized value $name in pattern match (m//) at C:/Perl/site/lib/Modu
le/ScanDeps.pm line 1353.
Use of uninitialized value $name in pattern match (m//) at C:/Perl/site/lib/Modu
le/ScanDeps.pm line 1354.
Use of uninitialized value $path in pattern match (m//) at C:/Perl/site/lib/Modu
le/ScanDeps.pm line 530.
Use of uninitialized value $file in hash element at C:/Perl/site/lib/Module/Scan
Deps.pm line 640.
Use of uninitialized value $file in string ne at C:/Perl/site/lib/Module/ScanDep
s.pm line 641.
Use of uninitialized value $file in pattern match (m//) at C:/Perl/site/lib/Modu
le/ScanDeps.pm line 643.
Use of uninitialized value $file in open at C:/Perl/site/lib/Module/ScanDeps.pm
line 761.
Use of uninitialized value $file in concatenation (.) or string at C:/Perl/site/
lib/Module/ScanDeps.pm line 761.
Cannot open : No such file or directory at C:/Perl/site/lib/Module/ScanDeps.pm l
ine 761.

Otra curiosidad, haciendo el comando inicial sin la variante de -M da el mismo error que con el comando -m

pp -o C:\Perl\proyectos\modulodecambio.exe C:\Perl\proyectos\modulodecambios.pl

error

C:\Perl\proyectos>modulodecambio.exe
AnyEvent: backend autodetection failed - did you properly install AnyEvent?

Module::ScanDeps es usado por pp.

También sale un aviso de que necesita el compilador gcc...

¿Es realmente tan necesario empaquetar el programa?

Yo no he empaquetado un programa Perl nunca.

La idea es dejar un .exe para que la instalación y ejecución sea simple, la GUI la tengo en C# y la idea es que llame a este .exe.

Respondiendo a la pregunta, lo del empaquetado es para evitar instalar el Perl en todos los equipos... y desde la GUI llamar al .exe. Posteriormente se pondrán configuraciones que si me interesa tener un poco guardas, aunque sea un poco...

He leído los temas referentes a cómo presentáis vuestros trabajos a los clientes y comparto plenamente la postura, pero necesito dejarlo al menos un poco cerrado y fácil de instalar y evitar problemas.

Por eso no se me ocurre otra forma de dejar cerrado en algunos .exe para que luego los técnicos se dediquen a instalarlo fácilmente.

Aprovecho esta pregunta para consultaros si el Perl 6 tiene contemplado empaquetar a .exe de alguna forma más sencilla... O seguiremos dependiendo de los módulos...

scout escribiste:He leído los temas referentes a cómo presentáis vuestros trabajos a los clientes y comparto plenamente la postura, pero necesito dejarlo al menos un poco cerrado y fácil de instalar y evitar problemas.

¿Qué problemas? Mis problemas terminan cuando el producto se entrega, se instala, se corren los test de prueba y se demuestra que todo funciona según los requerimientos. El cliente firma el parte de entrega, paga la parte final del contrato, y yo me marcho por la puerta.

Si el usuario o uno de sus técnicos empieza a jugar con los códigos, ya no es problema mío.

Si me llaman diciendo que algo no funciona, les recuerdo que el programa ha pasado los test de pruebas y que el cliente firmó el visto bueno.

Si me llaman para arreglarlo, les cobraré la misma tarifa que si fuera un fontanero (que, a propósito, es bastante alta).

scout escribiste:Por eso no se me ocurre otra forma de dejar cerrado en algunos .exe para que luego los técnicos se dediquen a instalarlo fácilmente.

Yo, algunas veces, les he enviado un fichero zip, indicando en qué lugar deben descomprimirlo. Bueno, esto fue cuando trabajaba en Windows. Ahora con Linux es más fácil.

scout escribiste:Aprovecho esta pregunta para consultaros si el Perl 6 tiene contemplado empaquetar a .exe de alguna forma más sencilla... O seguiremos dependiendo de los módulos...

Siempre dependeremos de los módulos... ¿Acaso los programas en .Net o Java no dependen de bibliotecas externas?

Ok, tomaré nota. El empaquetado lo logré hacer con el kit dev 8, por suerte, y luego de un par de ajustes salió bien.

Respecto al entorno de trabajo, bueno, estoy con un XP en una máquina virtual, ¡je,je! con el Perl v5.10, así no me voy perdiendo de las novedades del Perl y puedo seguir dando soporte a los script que ya tengo hecho…

Resumiendo, el Perl, por el momento, me viene salvando de todos los apuros… a nivel operativo.

Todo este tema me genera dos preguntas de diseño:

1.- en el caso de implementar un programa con Perl bajo la premisa de “no empaquetar”, ¿cómo tienes controladas las versiones de Perl instaladas y sus módulos en un entorno Windows con muchos ordenadores pero sin estar en dominio alguno?

2.- ¿Hay alguna forma de instalar Perl de forma desatendida y en caso de encontrar una versión que no sea la indicada poder pisarla por la que uno defina desde un script?

1.- dentro de los programas, tu puedes indicar qué versión de cada módulo que va a necesitar. Si no se cumple esa premisa, el programa termina con un aviso de error.

Ejemplo: si pongo al principio del programa

use 5.012;

entonces el programa no se ejecutará si el intérprete perl no es igual o superior a v5.12.

Para el caso de los módulos:

use CGI 3.34;

El programa no se ejecutará si no está presente una versión del módulo CGI que sea mayor o igual a 3.34.

Obviamente, es mucho mejor tener una sola máquina que haga de servidor de ficheros, compartir un subdirectorio, y en el resto de máquinas, crear una unidad de red y ajustar el valor de la variable de entorno PERL5LIB para que los programas accedan a los módulos contenidos en ese subdirectorio compartido.

De ésto, está brevemente comentado en la guía de uso del PPM gráfico. Así, solo una máquina sirve los módulos a todas las demás, con lo que reduces la complejidad de configurar los módulos de N máquinas, a solo una.

De otra forma, si se quiere replicar la misma configuración en todas las máquinas, una vez que se ha hecho la primera instalación del ActivePerl, el resto de actualizaciones son tan sencillas como hacer un zip de todo el árbol C:/Perl y distribuirlo por todas las demás (bueno, esto es cuando usé Perl en Windows, hace casi cinco años).

2.- Una forma sería con algún sistema de replicación de ficheros y directorios, tipo rsync. En Windows usé uno de la propia Micro$oft, que hacía la misma tarea, pero ahora ya ni me acuerdo cómo se llama. Sé que hacía copias incluso entre unidades de red.

Instalar Perl de forma desatendida, no me suena que exista. No sé si en .Net o Java existirá algo así. Lo que sí es cierto, es que instalar ActivePerl no es complicado.

Sí que puedes hacer una tarea programada que mire a ver la lista de módulos instalados, la compare con la indicada en algún servidor central, y avise, o ejecute ppm, para instalar las nuevas versiones de los módulos. Aquí puedes ver cómo hacer esa lista con ActivePerl.

Si hay que instalar módulos en máquinas que no tienen acceso a los repositorios, puedes usar paquetes ppmx.

En fin, que soluciones hay. Solo es cuestión de buscarlas y leerlas.

scout escribiste:2.- ¿Hay alguna forma de instalar Perl de forma desatendida y en caso de encontrar una versión que no sea la indicada poder pisarla por la que uno defina desde un script?

Tanto ActiveState como StrawberryPerl usan paquetes msi que puedes instalar de manera desatendida con el comando msiexec /i paquete.msi /qn .

Otra manera fácil de distribuir instalaciones de Perl es copiando la carpeta donde lo hayas instalado en un equipo a otro equipo (si añades módulos puedes usar robocopy para copiar sólo los cambios entre ambas carpetas; luego tienes que modificar las variables de entorno %PATH% para que perl.exe esté disponible y añadir la extensión pl a %PATHEXT% y así no tener que ejecutar el script como script.pl sino como script).

Otra manera, incluso, es compartir la carpeta donde hayas instalado Perl en la red y usar esa unidad de red desde los clientes: sufres una penalización en tiempo por el tráfico generado al cargarse todo desde la red, pero si tienes todo en Gigabyte Ethernet, a lo mejor es una opción a considerar. Evidentemente, sin conexión de red no hay Perl.

Yo copio la carpeta Perl con robocopy.

¡Justo! Era robocopy la utilidad que usábamos en Windows. ¡Jo!, ya ni me acordaba... es que fue hace muchos años.

Y la tercera opción que comenta natxo es la que yo te comenté, y es cierto que dependes de la velocidad de red, pero tienes la ventaja de que todas las máquinas trabajan con el mismo entorno.

¡Gracias, natxo!