¿Está poniendo todas las dependencies del proyecto dentro de las buenas prácticas del repository del proyecto?

Tengo un proyecto que usa paridades (por ahora ~ 6) dependencies (otras bibliotecas). La mayoría de ellos están en licencias MIT / BSD simplificadas, por lo que no debería ser un problema copyrlas a mi repository.

¿Sería una buena práctica poner todas esas bibliotecas en mi repository e insertlas (y cuando vengan nuevas versiones, actualizarlas también)? ¿O mi informe de proyecto solo debe contener los files del proyecto (código, activos, etc.)?

Pros:

  • la construcción es mucho más simple ya que tengo todo lo que necesito siempre cerca
  • Las bibliotecas agregadas significa que probé mi proyecto usando esas versiones, ya que otras (antiguas / nuevas) podrían crear algunos problemas

Contras:

  • hinchazón en el repository del proyecto
  • tiene que actualizar las dependencies a mano
  • si quisiera pegar también las versiones creadas, tendría que pegar mucho
  • files y tomaría mucho espacio, ¿así que probablemente solo se adhiera a la fuente?
  • algunas bibliotecas pueden no tener una licencia tan agradable y usarlas directamente (aparte de requerir que el usuario obtenga una biblioteca válida por sí mismo) y colocarlas en mi repository podría ocasionar algunos problemas

  • tener más proyectos para mantener las dependencies significaría que tengo que actualizarlos para todos los proyectos al mismo time (por ejemplo, si hago algunos otros proyectos dependiendo del proyecto actual (su biblioteca), todos tendrán las mismas dependencies)

Respuesta corta: depende.

Respuesta larga:

Antes de cuestionar si es apropiado o no include el código en su repository, debe preguntar si es apropiado controlar estrictamente las dependencies o estar más relajado.

La respuesta a eso depende de cómo distribuyas tu proyecto, qué quieren tus clientes / usuarios, si necesitas hacer cambios en el código fuente de las dependencies y cualquier otro requisito del proyecto.

Por ejemplo, suponga que está vendiendo un dispositivo de hardware y su código es el firmware del dispositivo. En este caso, es probable que desee controlar estrictamente las dependencies (requieren versiones muy específicas). Esto le brinda control total sobre todo el sistema, lo que simplifica las testings del sistema y puede ser importante si su dispositivo está sujeto a ciertos requisitos de security o confiabilidad (por ejemplo, es un dispositivo médico o una sonda enviada a Plutón). En general, si distribuye su producto en forma de una image binaria o de sistema de files, probablemente desee utilizar dependencies fijas.

Si desea que los usuarios puedan vincular dinámicamente con las versiones de las dependencies que vienen con sus sistemas (lo cual es valioso por muchas razones, incluidas las actualizaciones de security), probablemente desee relajar los requisitos. Aclare qué versiones son compatibles, limítese a las API documentadas disponibles en esas versiones, utilice una herramienta para aplicar los requisitos (error si la dependencia es demasiado antigua) y pruebe su código con tantas versiones de las dependencies como sea posible. .

Una vez que sepa con qué fuerza desea controlar sus dependencies, puede elegir el mecanismo utilizado para administrarlas. Puede usar una herramienta como Apache Ivy para get dependencies automáticamente, GNU Autoconf para aplicar versiones específicas, o puede extraer el código en su repository de Git y comstackrlo usted mismo. La elección específica no es tan importante; utilice lo que satisfaga sus requisitos y sea más fácil para usted y sus usuarios.