¿Por qué preferir un administrador de paquetes sobre una carpeta de biblioteca?

Cuando pienso en los pros y los contras de una carpeta de biblioteca estática y un administrador de paquetes, siento que la carpeta de la biblioteca es un mejor enfoque.

Pros que veo con una carpeta de biblioteca:

1. No necesita una herramienta externa para administrar paquetes.
2. No se requiere conexión a Internet para construir.
3. Construcción más rápida (sin verificación de paquete).
4. Entorno más simple (se requiere menos conocimiento).

Pros que veo con un administrador de paquetes:

1. Ayuda con los árboles de dependencia complejos (y eso se puede gestionar descargando una dependencia junto con todas sus dependencias).
2. Ayuda a verificar si hay una nueva versión disponible.

Parece que la industria ha decidido seguir el camino del administrador de paquetes para casi todo lo construido hoy. Entonces, ¿qué me estoy perdiendo?

Un punto importante que falta en las otras respuestas:

Usar un administrador de paquetes significa tener una configuración que indica qué versiones de biblioteca está utilizando y se asegura de que la información de configuración sea realmente correcta.

Saber qué bibliotecas usa y qué versión es muy importante si usted:

• necesita actualizar una biblioteca debido a un error crítico / agujero de seguridad;
• o simplemente necesita verificar si un agujero de seguridad anunciado le afecta.

Además, cuando realmente actualiza, el administrador de paquetes (generalmente) se asegura de que las dependencias transitivas se actualicen según sea necesario.

Mientras que con una libcarpeta, solo tiene un montón de archivos (posiblemente binarios y posiblemente modificados), y tendrá que adivinar de dónde provienen y qué versión son (o confiar en algunos README, que pueden ser correctos o no) )

Para abordar sus otros puntos:

No necesita herramientas externas para administrar paquetes.

Es cierto, pero a) como desarrollador de software, necesita instalar muchas herramientas de todos modos, por lo que una más no suele importar, yb) generalmente solo hay uno o unos pocos administradores de paquetes en un campo determinado (Maven / Gradle para Java, npm para JS / TypeScript, etc.), por lo que no es como si necesitaras instalar docenas de ellos.

No se requiere conexión a Internet para construir.

Todos los administradores de paquetes que conozco trabajan fuera de línea, una vez que han descargado las dependencias requeridas (lo que puede suceder inmediatamente después de descargar el proyecto en sí).

Construcción más rápida (sin verificación de paquete).

Probablemente sea cierto, pero parece poco probable que la verificación del paquete fuera de línea tome una cantidad de tiempo significativa (solo compara algunos números de versión). Una verificación en línea puede llevar un tiempo, pero se puede desactivar si se desea (si está activada de manera predeterminada; Maven, por ejemplo, nunca busca actualizaciones para las versiones de lanzamiento).

Entornos más simples (se requieren menos conocimientos).

Es cierto, pero como se explicó anteriormente, una libcarpeta también requiere conocimiento. Además, como se explicó anteriormente, probablemente solo trabaje con un puñado de administradores de paquetes diferentes, que ya sabrá.

Los pros de la carpeta lib desaparecen rápidamente después de pasar del desarrollo a pequeña escala a un trabajo más grande.

Por ejemplo, el "beneficio" de no requerir una herramienta externa se ve superado por el trabajo requerido para administrar manualmente sus dependencias, por lo que la herramienta será usted (en más de un sentido del mundo).

No necesita una conexión a Internet para un administrador de paquetes. Puedes usar repositorios locales.

Una compilación más rápida puede ser cierta, pero no es algo que deba determinar si se debe usar un administrador de paquetes o no. No estamos hablando de magnitudes de diferencia después de todo, y esto también depende de su configuración. Puede hacer una compilación lenta fácilmente usando un administrador de paquetes, pero eso es básicamente un sabotaje.

¿Entornos más simples (se requieren menos conocimientos)? Nuevamente, en el desarrollo a pequeña escala definitivamente es una posibilidad. Es posible que pueda mantener el proyecto en su cabeza por completo, hasta cada una de las pocas bibliotecas que se utilizan. Agregue un simple archivo make / otro script de compilación y obtendrá un paquete completo.

Pero no simplifica los entornos, solo funciona en entornos simples. En el desarrollo a gran escala, estará contento de que esté utilizando herramientas estándar en lugar de soluciones personalizadas. Después de todo, solo tiene que aprenderlo una vez (y cuando el administrador de paquetes del día es reemplazado por algo nuevo y genial, también debe aprenderlo).

Te estás perdiendo muchas de las ventajas de los administradores de paquetes.

1. Los administradores de paquetes le permiten evitar el ingreso de binarios grandes (varios megabytes o más grandes) en el control de origen. Hacerlo es anatema para muchas herramientas de control de fuente, siendo el git dominante una de ellas. Tuvimos un repositorio que alcanzó los límites de tamaño de Bit Bucket hace un par de meses porque los desarrolladores estaban registrando CocoaPods. Otro proyecto ya estaba a mitad de camino cuando migramos de SVN porque habíamos estado revisando todos nuestros binarios lib (y no habíamos estado usando NuGet). Dado que los administradores de paquetes descargarán paquetes sobre la marcha para cada desarrollador, eliminan la necesidad de registrar estos archivos binarios.
2. Evitan mezclar archivos / bibliotecas incompatibles. Las carpetas pueden contener versiones mixtas de los archivos de la biblioteca si alguien no lo limpia correctamente durante una actualización. He visto un caso en el que se actualizaron la mitad de los archivos binarios de la carpeta, lo que resultó en errores muy extraños. (¡Ni siquiera se bloqueó!) Nos tomó literalmente meses (no horas hombre, solo tiempo general) para resolver el problema. Al permitir que el administrador de paquetes controle toda la carpeta, no puede obtener versiones mixtas; Aseguras consistencia. También hacen que sea mucho más difícil usar dependencias incompatibles , al actualizar automáticamente todo junto, instalar diferentes versiones donde sea necesario, o incluso simplemente lanzar advertencias o errores al intentar usar versiones incompatibles de bibliotecas.
3. Establecen una convención compartida para administrar bibliotecas. Cuando los nuevos desarrolladores ingresan a su proyecto, equipo, empresa, etc., es probable que conozcan las convenciones del administrador de paquetes. Esto significa que no tienen que perder el tiempo descubriendo los detalles de cómo se administran las bibliotecas en su base de código.
4. Le proporcionan una forma estándar de versionar y distribuir sus propias dependencias y archivos que no pertenecen a su repositorio. Incluso los he aprovechado personalmente para algunos archivos de datos estáticos grandes que requería mi aplicación, por lo que funciona bien para versionar cosas además del código binario.
5. Algunos administradores de paquetes proporcionan características adicionales durante la instalación. NuGet agregará dependencias y archivos de contenido a su archivo csproj e incluso puede agregar elementos de configuración al archivo de configuración.
6. Sus archivos de lista de paquetes documentan las versiones de sus bibliotecas en un solo lugar centralizado. No tengo que hacer clic con el botón derecho en una DLL y mirar el número de versión para averiguar qué versión de la biblioteca estoy usando. En Python, es posible que el autor de la biblioteca ni siquiera haya incluido el número de versión en los archivos py, por lo que es posible que ni siquiera pueda distinguir la versión de la biblioteca.
7. Desalientan la instalación de dependencias en toda la máquina. Los gestores de paquetes proporcionan una forma convencional de instalar dependencias sin un instalador global . Cuando sus opciones son la carpeta lib y la instalación global, muchos desarrolladores de bibliotecas elegirán ofrecer sus bibliotecas primarias como instalaciones globales en lugar de como archivos binarios descargables que debe configurar usted mismo. (El historial de MS lo demuestra. También es el caso de muchas bibliotecas en Linux). Esto en realidad dificulta la administración de múltiples proyectos, ya que puede tener proyectos con versiones en conflicto y algunos desarrolladores ciertamente elegirán la instalación global aparentemente más simple en lugar de tener su propia biblioteca dir.
8. Tienden a centralizar el alojamiento y la distribución. Ya no tiene que depender del sitio web de esa biblioteca aleatoria. Si cierran, el sitio de un administrador de paquetes exitoso todavía tiene todas las versiones cargadas. Los desarrolladores tampoco tienen que buscar muchos sitios web solo para descargar nuevas bibliotecas; tienen un lugar al que buscar primero e incluso buscar diferentes opciones. También es más fácil duplicar paquetes organizados de manera estándar que alojar manualmente copias de todo desde sitios web ad-hoc.

También está exagerando el valor de sus "beneficios".

1. No necesita herramientas externas para administrar paquetes.

   ¿"Externo" a qué? Compruebo el ejecutable NuGet en mis repositorios. Es el único binario que me siento bien registrando, ya que es pequeño y significa que no necesito registrar ningún otro binario.

   pip no plantea problemas en este frente ya que ahora está incluido en Python de manera predeterminada y los cambios incompatibles de ruptura y hacia atrás son extremadamente raros. De todos modos, no va a desarrollar código Python sin tener Python instalado externamente en su proyecto.

   Cuando llegan a una adopción generalizada, los administradores de paquetes tienden a ser muy estables. No puede escapar sin algún tipo de herramientas instaladas a nivel mundial para la mayoría de los proyectos, y un único administrador de paquetes es un requisito bastante ligero. Por lo general, no es mucho más engorroso que tener instalado Language Runtime.

2. No se requiere conexión a Internet para construir.

   No puedo conectarme a mi base de datos sin una conexión de red. Si la base de datos está alojada en Amazon, de todos modos necesito una conexión a Internet completa. Necesito una conexión a Internet para impulsar y extraer cambios a través del control de fuente; un servidor de compilación tampoco puede verificar el código para compilar sin algún tipo de conexión de red. No puede enviar ni recibir correos electrónicos sin uno. ¡No puede descargar bibliotecas para ponerlas en su carpeta lib sin una! El desarrollo permanente sin conexión a Internet es prácticamente desconocido. En algunos casos raros donde es necesario, puede lidiar con esto descargando los paquetes a una ubicación que el administrador de paquetes pueda consumir. (Sé que NuGet y pip están muy contentos de extraerlos de una carpeta o unidad de red simple; sospecho que la mayoría de los demás también pueden hacerlo).

3. Construcción más rápida (sin verificación de paquete).

   30 segundos durante la compilación automatizada y 5 segundos durante la compilación de desarrollo local son una buena compensación por los beneficios que describí anteriormente. Estos son plazos triviales que generalmente ni siquiera vale la pena considerar en comparación con los problemas que resuelven los beneficios.

4. Entornos más simples (se requieren menos conocimientos).

   De todos modos, una herramienta para la administración de paquetes contra nada para la administración de bibliotecas no es realmente una comparación justa. Sin la herramienta, debe aprender cualquier proceso personalizado que esté utilizando el proyectopara administrar sus bibliotecas. Esto significa que nunca está seguro de si su conocimiento existente se aplica a cualquier proyecto nuevo que aborde. Tendrás que lidiar con cualquier enfoque de mezcolanza que alguien haya inventado, o inventar el tuyo. Ese podría ser un directorio que contiene todas las bibliotecas, o podría ser algo mucho más extraño. Tal vez para evitar registrar las bibliotecas, alguien las puso todas en una unidad de red y el único indicador de versión es el nombre de la carpeta. ¿Cómo es eso o una instalación global realmente mejor? En comparación, un administrador de paquetes le brinda una convención limpia que se aplicará en la mayoría de los proyectos que encuentre.

El tema común es que proporcionan coherencia, documentación y características no solo dentro de los proyectos, sino incluso entre ellos. Esto simplifica la vida de todos.

Tras haber convertido recientemente nuestro producto del uso de bibliotecas descargadas manualmente a la gestión automática de paquetes con Nuget, puedo decir que usar un administrador de paquetes tiene enormes beneficios.

Nuestro producto se implementa en 27 proyectos de C #, que es relativamente pequeño para los estándares actuales. Algunas de nuestras dependencias de terceros tienen docenas de ensamblajes.

Antes de Nuget, si quisiera actualizar todas nuestras dependencias a la última versión, tendría que:

1. Localizar dónde podría obtener todas las bibliotecas actualizadas
2. Descárguelos y descomprímalos / instálelos
3. Agregue las nuevas versiones al control de origen
4. Revise manualmente todas las referencias en nuestros proyectos y actualícelas para que apunten a los nuevos ensamblajes

Con 27 proyectos y docenas de ensambles de dependencia, este proceso era muy propenso a errores y podía llevar horas.

Ahora que hemos actualizado el uso de Nuget, todo está hecho para mí con un solo comando.

No necesita herramientas externas para administrar paquetes

Eso no es un punto, ¿verdad? Si uso un administrador de paquetes, no necesito tener una carpeta lib. Tampoco tengo que administrar los paquetes yo mismo.

No se requiere conexión a Internet para construir

Además de que no tener una conexión a Internet hoy en día mientras se desarrolla es algo raro (tal vez con la excepción de estar en tránsito), un administrador de paquetes decente no debería requerir que tenga la última versión para construir su aplicación. Puede quejarse, pero no hay razón para no compilar con la versión que ya instaló

Compilación más rápida (sin verificación de paquetes)

Ese es un impulso de velocidad bastante marginal, pero podría decirse que es posible.

Entornos más simples (se requieren menos conocimientos)

La mayoría de los administradores de paquetes son tan simples en estos días que apenas vale la pena tratar de evitarlos haciendo esto. Incluso hay clientes visuales si quieres. En realidad, ocultan una gran parte de la corteza que está sucediendo.

Los administradores de paquetes también le permiten compartir estos paquetes entre diferentes proyectos. Si 5 de mis proyectos usan la misma versión de Boost, no hay necesidad de duplicar esto para cada proyecto. Esto es especialmente cierto para los complejos árboles de dependencia de los que habla.

Con una carpeta lib, administra paquetes solo para ese proyecto, mientras que un administrador de paquetes le permite hacer esto para todo su entorno de desarrollo con una sola herramienta.

Es la diferencia entre simplemente usar bibliotecas (directorio lib) y usarlas, mantener la metainformación (administrador de paquetes) . Dicha metainformación se refiere a números de versión, dependencias (transitivas) entre bibliotecas y demás.

Las discusiones sobre el infierno de DLL, la compatibilidad de la biblioteca, el sistema de módulos Java, OSGi y demás deberían ser, por lo menos, suficientes para convencer de algún valor de tener alguna forma de gestión de dependencias.

• La versión de la biblioteca y los problemas de dependencia pueden ser una pérdida de tiempo.

También existe el beneficio de un repositorio compartido (local), por lo que varios proyectos no necesitan mantener copias de las librerías importadas. Si uno tiene un proyecto con 20 submódulos, algunos de esos módulos tienen 40 dependencias impares.

• Más estructura
• Más recorte de bibliotecas
• No hay decisiones humanas ad-hoc sobre bibliotecas

Hay algunos casos en los que podría ser necesaria una carpeta lib, por ejemplo, cuando se trata de bibliotecas obsoletas (una versión que ya no se mantiene / disponible), una versión localmente modificada de una biblioteca, ...

Pero para todo lo demás, es como si el desarrollador asumiera el rol de administrador de paquetes:

• El desarrollador tendrá que descargar las bibliotecas (se requiere internet)
• El desarrollador tendrá que buscar manualmente nuevas versiones
• ...

Y en mi humilde opinión, se requiere menos conocimiento, porque hay que aprender sobre el uso de la herramienta externa, pero menos sobre las bibliotecas (es decir, dependencias).

Hay otro problema no cubierto por otras preguntas: compartir departamentos.

Digamos que tienes dos paquetes construyendo la misma biblioteca. En el mejor de los casos, no habrá ningún cóctel, pero el mismo espacio HDD / SSD se usará dos veces. En el peor de los casos, habrá varios conflictos, como versiones.

Si usa el administrador de paquetes, instalará la biblioteca solo una vez (por versión) y ya le proporcionará la ruta.

PD: por supuesto, necesitas un enlace dinámico (o una función similar en tu idioma) para obtener este profesional.

Una de las principales razones por las que las bibliotecas compartidas se consideraban un elemento de progreso en los sistemas Unix y Windows de la era de los 90 era cómo podían reducir el uso de RAM cuando se cargaban múltiples programas que usaban el mismo conjunto de bibliotecas. El espacio de código solo necesita asignarse UNA VEZ por biblioteca exacta y versión de esa biblioteca , el único uso de memoria por instancia restante es para variables estáticas.

Muchos sistemas operativos implementan bibliotecas compartidas de una manera que depende de mecanismos como la api mmap () de Unix, lo que implica que una biblioteca no solo necesitará ser exactamente la misma versión, sino realmente el mismo ARCHIVO. Esto es simplemente imposible de aprovechar al máximo para un programa que incluye su propio conjunto de bibliotecas.

Dado que la memoria es mucho más barata y las versiones de la biblioteca necesitaban más diversidad que en los años 90, este argumento no tiene tanto peso hoy en día.