[Madrid-pm] Dependencias de los módulos

Pablo Rodriguez pablo.rodriguez.gonzalez en gmail.com
Dom Oct 9 11:38:32 PDT 2016


Muy buen artículo Joaquín!!

¿Alguien más se anima a compartir su opinión?

El 3 de octubre de 2016, 10:28, Joaquin Ferrero <explorer en joaquinferrero.com
> escribió:

>
>
> 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/SemVe
>> r 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
> Madrid-pm en pm.org
> http://mail.pm.org/mailman/listinfo/madrid-pm
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.pm.org/pipermail/madrid-pm/attachments/20161009/744f2173/attachment-0001.html>


Más información sobre la lista de distribución Madrid-pm