perl - pagina - ¿Por qué no usas los módulos de CPAN?

perl package manager (11)

ETA: Cuando pregunto "¿Por qué no usa los módulos de CPAN?", Me refiero a las personas que se niegan a utilizar los módulos de CPAN (incluidos los de alta calidad como DBI ). No todos los códigos CPAN son de alta calidad, y está bien alejarse de los módulos que son triviales o están basados en código experimental (el otro día me molestó un desarrollador por querer traer Time::Format solo porque no lo hizo). no sé que strftime estaba en POSIX ).

Recientemente, en Perl Beginners , alguien quiere saber cómo hacer algo sin recurrir al módulo Perl comúnmente sugerido para esa función. Él o ella no desea instalar el módulo de CPAN. Esto me hizo pensar en las razones por las que he visto a las personas evitar el uso de CPAN y se me ocurrieron cinco razones para este comportamiento y la solución para cada una:

te asustan (respuesta, superarlo)
asustan a sus administradores de sistemas (responda, solucione su problema instalándolos en su directorio de inicio y use el pragma de lib)
está utilizando un servicio de alojamiento que le impide instalar módulos (respuesta, obtener un mejor servicio, servicios baratos que no se comportan como idiotas)
la máquina de destino no tiene necesariamente el módulo necesario (respuesta, use PAR o PAR :: Packer)
la máquina de destino está totalmente bloqueada (es decir, usted inicia sesión en rbash y debe proporcionar el código a un tercero para incluirlo en la casilla) (una combinación de 4 y atravesando la burocracia)
Está utilizando una versión incorporada de Perl que no puede cargar módulos (sin respuesta, está atascado, pero esto es muy raro)

Entonces, si no usa CPAN, ¿por qué y por qué las respuestas anteriores no son adecuadas? Tenga en cuenta que no estoy preguntando por qué no se instala directamente desde CPAN en el boxen de producción. Estoy preguntando por qué evita usar los módulos de CPAN (la instalación a través del sistema de paquetes cuenta como usar CPAN para mí).

la máquina de destino no tiene necesariamente el módulo necesario

Esto puede ser válido en algunos entornos. Uno de mis amigos trabaja en un enorme mega conglomerado que abarca países y continentes. Con frecuencia, usa Perl para hacer que las unidades de cinta hagan cosas en todo el mundo. Los scripts se deben implementar en literalmente miles de máquinas y la instalación de módulos es realmente un gran problema, generalmente involucrando un comité y administradores de sistemas múltiples en cada ubicación física. Tiende a evitarlos a toda costa y no puedo decir que lo culpe.

¿Hay una solución para eso? Realmente no creo que exista.

(Esto de arriba es un corte y pega de mi respuesta a una pregunta realmente similar sobre permonks).

http://perlmonks.org/?node_id=750387

(respuesta, use PAR o PAR :: Packer)

Una vez le sugerí PAR, pero no fue práctico en absoluto. Ninguna de las máquinas es lo suficientemente similar para que PAR sea realmente útil en un caso general. Sus opciones eran: no use módulos ni mantenga 1300 binarios PAR. PAR es bastante difícil de trabajar realmente bien incluso cuando definitivamente conoces la forma de patrón objetivo, por lo que eligió no usar módulos.

Algunos de los módulos están basados en librerías de código abierto y no compilan ni se comportan bien en todos los entornos chiflados que tienes. Considere, por ejemplo, la necesidad de ejecutar en NCR, HP, SUN, Linux y AIX.

Aquí hay una razón válida que se me ocurre: usted quiere descubrir cómo hacerlo usted mismo. Lo cual está bien, siempre y cuando se dé cuenta de que un entorno de producción no es para sus propios experimentos personales.

Uno podría decir "bien mire cómo lo hace el módulo CPAN", pero leer la implementación de alguien más no es un buen sustituto para hacerlo usted mismo. Y, sinceramente, muchas implementaciones de CPAN son aterradoras. Esto puede ser despectivo en cuanto a la calidad del código CPAN, pero también es una historia de éxito sobre cuán bien encapsulado y probado está un módulo CPAN que en su mayoría no se da cuenta.

En cuanto a todas las respuestas que son variaciones sobre "el shell CPAN es difícil de configurar", estoy de acuerdo. Sin embargo, este es un problema O (1). Lo resuelve una vez y luego obtiene un fácil acceso a CPAN por el resto de su vida.

El host de destino tiene un sistema operativo incómodo que no está bien soportado por los módulos de CPAN (debido en parte a la falta de probadores de CPAN ).

Tales ejemplos son AIX y HP-UX. Tienen un antiguo perl, ya sea un compilador de C o uno viejo / roto y bibliotecas viejas / rotas, por lo que demasiados módulos XS no se pueden instalar de inmediato. Aplicar parches lleva tiempo (especialmente cuando el autor CPAN no responde durante meses), y tratar de solucionar los módulos XS no es posible en la práctica (bueno, si realmente quieres ir de esa manera, tendrás demasiadas veces para parchar módulos perl puros) que dependen de los módulos XS).

Esta es una respuesta con un enfoque positivo, es decir, dice cómo puede solucionar las restricciones que le impiden utilizar los módulos de CPAN: Sí, incluso puede usar CPAN .

Hay algunas razones por las que a veces aconsejo a las personas que no usen ciertos módulos de CPAN. No todos los CPAN son códigos de alta calidad, y existen diferentes niveles de mantenimiento para diferentes distribuciones. Todos deben considerar cuánto trabajo deben hacer para usar un módulo de CPAN en particular y qué guarda ese módulo (es decir, el costo total de propiedad). Usar cualquier módulo de CPAN en particular no siempre es un beneficio. No digo que las personas no deberían usar CPAN, pero deberían considerar lo que realmente necesitan de él.

Una dependencia de módulo externo permite a otra persona romper su aplicación. La cadena de herramientas CPAN solo se preocupa por la última versión de un módulo y puede actualizar su instalación cuando ve que tiene una versión anterior. He visto que muchas aplicaciones se rompen cuando las dependencias externas subyacentes presentan nuevos errores, funciones necesarias obsoletas, etc. Es una de las razones por las que he estado desarrollando mis herramientas para que las empresas alberguen sus propios repositorios de CPAN para que puedan controlar eso. Hay otras maneras de mitigar eso, pero no muchas personas son lo suficientemente sofisticadas como para tener un buen proceso para ello.
Usted trabaja en un entorno donde todo el código debe ser aprobado. Esto parece un requisito estúpido para mucha gente, pero la gente de gestión de riesgos también tiene un trabajo que hacer. A veces, el cumplimiento es obligatorio según diversas leyes, normas de atención, etc. A menos que el módulo realmente ahorre mucho tiempo y energía, es posible que el beneficio no valga la pena para pasar por ese proceso. Realmente, ¿cuántos de ustedes alguna vez inspeccionaron seriamente el código que obtienen de CPAN? Podría haber algo allí.
Algunos módulos de CPAN implementan funcionalidades codificadas trivialmente. Usar un módulo solo porque está en CPAN y no quiere escribir las tres líneas de código es un poco tonto. Puedes hablar sobre la reutilización de código todo lo que quieras, pero eventualmente eso es reductio ad absurdum .
La instalación de algunos módulos puede ser bastante complicada, frágil e impredecible, y en ocasiones esto se debe a la larga lista de dependencias para simplemente compilar y probar el módulo, aunque no necesite esas dependencias para usar realmente el módulo. Lleva mucho trabajo manejar estos casos en entornos de prueba automatizados.
Algunos autores de CPAN son codificadores experimentales, no mantenedores. Crear dependencias en su trabajo significa que terminas con un módulo no compatible que no recibe parches y nadie más realmente se preocupa por él. Obtener los parches aceptados es realmente un gran problema para algunos proyectos importantes, y no se puede corregir el autor que no responde sin recurrir a algún proceso para utilizar una versión localmente parcheada y no se sobrescribe con la cadena de herramientas de CPAN.

No escapa a estos motivos con respuestas simplistas sobre el uso de otro servicio, la instalación en un directorio local, etc. No puede aplicar sus argumentos contrarios a cada situación y configuración. Cualquier persona que le diga lo contrario, como la publicación superior en las Siete Razones (Malas) Razones para No Usar los Módulos con los que se vincula Leon, realmente no está pensando en la situación de nadie, y hay muchos argumentos contramenor pensativos.

Nunca empieces desde la posición de pensar que alguien debería o no debería usar CPAN. Evalúe la situación local, evalúe los riesgos y las recompensas, desarrolle salvaguardas para los riesgos y use los módulos sabiamente. Eso no es diferente de cualquier otro tipo de desarrollo de software serio o práctica comercial.

Instalar módulos Perl localmente es un poco desafiante. Aquí está mi proceso:

Configurar la configuración de CPAN localizada por el usuario:

mkdir -p ~/.cpan/CPAN touch ~/.cpan/CPAN/MyConfig.pm

Si CPAN se configuró previamente para el administrador de todo el sitio (es decir, está en su propio cuadro y ya está encendido y configurado CPAN), puede cambiar a usuario local por: " perl -MCPAN -e mkmyconfig ". Luego, edite " ~/.cpan/CPAN/MyConfig.pm ":

''makepl_arg'' => q[LIB=/home/your_name/perllib],

De lo contrario, puede iniciar CPAN normalmente: " perl -MCPAN -e shell " o simplemente " cpan ". Se te pedirá configuración. En el "Parámetros para el comando ''perl Makefile.PL''?", Escriba: " PREFIX=~ LIB=~/lib/perl5 ".

Para hacer referencia a los módulos instalados localmente en sus scripts de Perl, puede hacer use lib pragma, pero creo que es una dependencia molesta cuando tiene numerosos scripts y módulos de Perl para actualizar en su aplicación. Esto es más de una solución.

En cambio, puedo configurar el entorno var PERL5LIB en la ruta donde el módulo se instaló localmente, como " $HOME/lib/perl5 ". Para establecer PERL5LIB para un entorno CGI, PERL5LIB cómo establecer variables de entorno en la configuración del servidor. En Apache, puedo hacer eso en httpd.conf o en .htaccess usando mod_env. (gracias, Brian Foy)

Me alegra que hayas preguntado.

Estaba pensando hacer una pregunta como "¿Por qué CPAN tiene que chupar tanto?" pero decidí que no valía la pena sacrificar mi reputación cuando yo (creo que) ya sabía la respuesta. Y como esta pregunta está marcada como "subjetiva", le agradeceré que no me modere por dar mi opinión personal sobre este tema, incluso si piensa que estoy equivocado o es estúpido.

Primero algunos antecedentes: hice bastante codificación Perl a mediados de los años noventa y lo disfruté, pero al final llegué a la conclusión de que el lenguaje carecía de muchas características que eran necesarias para una programación "real" orientada a objetos. Me convertí en desarrollador de C ++ durante varios años y ahora soy un gerente de proyectos muy técnico. Todavía uso Perl para scripts y truncado de datos y otros bits y piezas, y recientemente comencé a usar los scripts de Perl para probar los servicios web que nuestros codificadores han desarrollado.

De todos modos, llegué al desbordamiento de la pila para la gestión del proyecto, pero me quedé para el Perl. Me complace ver que el lenguaje ha crecido y tiene todo tipo de módulos fantásticos como Moose y MVC y plantillas, y así sucesivamente, y me gustaría utilizarlos ... y lo haré. Pero lleva tiempo, y solo tengo unas pocas horas para trabajar con ello. ¿Por qué no es fácil?

Pero para responder la pregunta ...

Primero, la respuesta obvia: la mayoría de los programas Perl no necesitan módulos CPAN.
Hay más de una forma de hacerlo. No necesito módulos para hacer muchas cosas que usaría módulos si fuera fácil hacerlo. Por ejemplo, he estado analizando documentos XML con split () y expresiones regulares. Sé que está mal (pero el primer paso para la recuperación es admitir que tienes un problema). Pero puedo copiar y pegar el código para hacer esto en unos pocos segundos, o puedo irme y tratar de hacer que cpan funcione durante un mes más o menos.
Ahora vamos a ser un poco más controvertido. CPAN es frágil A principios de este año, traté de usar Cpan para instalar Moose porque había leído cosas buenas sobre él y estaba ansioso por hacer la programación adecuada de OO en Perl y que no fuera dura / fea. Así que seguí las instrucciones de instalación, y presioné ''Y'' cientos de veces (al parecer) antes de ser descargado con páginas y páginas de advertencias del compilador en el paso final. ¿Qué demonios hago ahora? Mi principal caja de desarrollo tiene algún tipo de módulo de Moose medio roto esperando (estoy seguro) para morderme el culo cuando menos lo espero. Eso fue hace unos dos meses, y no he vuelto. Yo especulo que muchos Perl / CPAN tienen dependencias en otros lenguajes de programación y eso los hace más frágiles (a diferencia de los lenguajes cuyas bibliotecas están codificadas en el mismo idioma). Además, especulo que experiencias como esta asustan a los usuarios potenciales.
La documentación para principiantes CPAN es pobre. ¿Dónde está la documentación autorizada de CPAN de todos modos? ¿Dónde está la introducción y tutoriales para principiantes? ¿Y cómo se supone que debo saber eso? He estado leyendo y quitando la documentación de CPAN durante algunos meses, y estoy empezando a descubrir dónde están las cosas. (Veo que casi todos los módulos individuales de Perl en CPAN están bellamente documentados internamente, pero tardé mucho tiempo en encontrar esa documentación).
El proceso de instalación es muy difícil. Cuatro pasos y cientos de avisos pueden haber estado bien hace diez años, cuando había menos paquetes y menos dependencias, pero ahora es una mierda. ¿Por qué no puedo simplemente escribir algo como ''cpan-install Moose'' en mi caparazón y hacer que se haga? Esto es particularmente extraño, dado que los usuarios avanzados a menudo afirman que la portabilidad es una virtud, citando cosas como paquetes y PAR que aún no entiendo. ¿Y por qué la instalación local es aún más difícil cuando tanta gente parece querer hacerlo?
Existen problemas molestos, como si debo instalar módulos de CPAN con cpan o con el sistema de administración de paquetes, donde el asesoramiento es inconsistente. De manera más general: hay más de una forma de hacerlo. Y cuando comienzas a hacer Perl avanzado, tienes que tomar decisiones sobre cómo instalar módulos y qué módulos usar y por dónde comienzas? Recuerde que es un principiante y la documentación está algo fragmentada y la curva de aprendizaje es abrupta. Mi solución ha sido tratar de evitar esto al no usar cpan mientras leo un poco más.
Finalmente, Perl avanzado tiene una curva de aprendizaje muy empinada. Los usuarios avanzados de Perl aparentemente no recuerdan esto y no pueden verlo. IMO existe una gran diferencia entre usar Perl como se concibió originalmente -como un lenguaje práctico de extracción e informe con potentes expresiones regulares- y usarlo como una plataforma de desarrollo moderna con OO y plantillas y MVC y todo tipo de otros objetos . Aún no he encontrado un camino suave e incremental desde el uso ocasional de Perl hasta el uso avanzado de Perl.

Ahí vas. Disculpas por la diatriba.

Puede encontrar este ensayo (y sus comentarios) interesante.

Puede tener el motor de secuencias de comandos de Perl incrustado en una aplicación host (por ejemplo, un servidor web o cualquier aplicación compleja que requiera secuencias de comandos), y tiene muchas restricciones en ese contexto incrustado, como no poder cargar archivos.

Si las cosas "asustan a los administradores del sistema" lo suficiente, no quieren que los pongas en la máquina, independientemente de dónde creas que los pondrás. Las tiendas tienen estándares por una razón.

No hay distribución de responsabilidad con un módulo de CPAN. En la tienda en la que trabajo actualmente, tenemos tal trato con nuestro proveedor de software de contabilidad encapsulado. Los llamamos en el medio de la noche si nuestra aplicación no funciona y necesitamos su experiencia. Porque si nuestros cálculos se estropean lo suficiente, nuestro contrato con ellos asegura que pagarán parte de la factura, dependiendo de su exposición con un problema determinado.

Cuando sales al mundo real, donde las secuencias de comandos de Perl se ejecutan junto con COBOL de 40 años de antigüedad, establecido, crujiente, puedes comprender cuánto más a gusto los gerentes están con la ejecución del COBOL que con "guiones" que dependen en gran medida de la ardiente aficionados, sin embargo inteligente.

Dicho esto, mi tienda actual es bastante cómoda con Perl para scripts e informes no críticos, e instalaré ocasionalmente el módulo CPAN, pero el proceso de aprobación es riguroso, las pruebas de sandbox son largas (¡y caras!), Pero lo hacen posible. Solo puedo imaginar que podrían aprobar uno o dos módulos nuevos, no más de 50 módulos nuevos, debido a la cantidad de situaciones nuevas a las que los expondrían. Por lo tanto, los módulos creados por el grupo "Vamos a usar CPAN" están casi descartados si alguna dependencia dice "No recomendado para código de producción" o "experimental".