El 02/10/16 a las 14:12, Pablo Rodriguez escribió:
Buenos días
En las cañas posteriores a la reunión hablabamos de las dependencias
de los módulos, y que a veces era un criterio muy importante para
elegir un módulo u otro. Es decir, elegiamos un módulo porque no tenía
dependencias frente a otros que sí tenían.
La carga de la complejidad informática que resuelve un problema es casi
la misma -el número de líneas que necesitamos para resolver un problema
es casi el mismo si usamos muchas o pocas dependencias: no hay atajos en
la resolución del problema-. Pero solemos pensar que si usamos un módulo
con pocas dependencias reducimos otra complejidad: la de la
administración de los módulos de terceros. ¿Realmente es un problema, si
estamos seguros que esos módulos funcionan en nuestro entorno?
Otro tema que salió por parte de Roberto es que tenían hecho una
herramienta que analizaba un directorio cualquiera para sacar las
dependencias del código Perl encontrado. ¿Era así, verdad?
En CPAN encontré Module::Dependency
<https://metacpan.org/release/Module-Dependency>, más en concreto,
Module::Dependency::Indexer, que parece que hace algo parecido, pero no
lo he probado. Y posiblemente habrá más.
Comenté también que había un módulo que permitía cargar un módulo en
CPAN en tiempo real:
CPAN::AutoINC <https://metacpan.org/pod/CPAN::AutoINC> - Download and
install CPAN modules upon first use
Mejor dicho: detecta que un programa necesita un módulo que no está en
el sistema, y en ese momento lo baja, instala, y el programa continúa en
ese punto.
A mi me gusta tener funcionalidad reutilizable, es decir, partiendo de
una serie de componentes construir sobre ellos. Personalmente creo que
tiene más ventajas que inconvenientes, y no tengo ningún problema en
utilizar módulos con muchas dependencias. Si además los autores de los
módulos se adhieren a alguna convención, por ejemplo:
https://metacpan.org/pod/SemVer mejor todavía.
¿Qué opinais?
Por lo que he visto en algunos sitios, a medida de que dependes de más
módulos, se te hace imprescindible usar un gestor de módulos, como Pinto
y Carton, y no depender exclusivamente de CPAN.
Un ejemplo: Una vez usé el módulo *Date::Set*, para hacer operaciones de
conjuntos con periodos de tiempo (en concreto, "unir" conjuntos de
meses). Pues bien, un día ese módulo desapareció de CPAN: el autor lo
renombró a *DateTime::Set*. Eso podría provocar un problema a la hora de
hacer una reinstalación, si el administrador no se da cuenta del cambio.
Este artículo es un buen resumen de las herramientas actuales con las
que contamos en desarrollo Perl, incluida la gestión de módulos propios
y de terceros:
https://engineering.semantics3.com/2016/06/15/a-perl-toolchain-for-building-micro-services-at-scale/
--
JF^D
_______________________________________________
Madrid-pm mailing list
[email protected]
http://mail.pm.org/mailman/listinfo/madrid-pm
