Pourquoi préférer un gestionnaire de paquets à un dossier de bibliothèque?

Quand je pense aux avantages et aux inconvénients d’un dossier de bibliothèque statique et d’un gestionnaire de paquets, j’ai l’impression que le dossier de bibliothèque est une meilleure approche.

Je vois avec un dossier de bibliothèque:

1. Pas besoin d'un outil externe pour gérer les packages.
2. Aucune connexion Internet requise pour construire.
3. Construction plus rapide (pas de vérification de paquet).
4. Environnement plus simple (moins de connaissances requises).

Je vois avec un gestionnaire de paquets:

1. Aide avec des arbres de dépendance complexes (et qui peuvent être gérés en téléchargeant une dépendance avec toutes ses dépendances).
2. Aide à vérifier si une nouvelle version est disponible.

Il semble que l'industrie ait décidé de suivre le chemin du gestionnaire de paquets pour presque tout ce qui est construit aujourd'hui. Alors, qu'est-ce qui me manque?

Un point important manque dans les autres réponses:

Utiliser un gestionnaire de paquets signifie avoir une configuration qui indique les versions de bibliothèque que vous utilisez et garantit que les informations de configuration sont réellement correctes.

Savoir quelles bibliothèques vous utilisez et quelle version est très important si vous:

• nécessité de mettre à jour une bibliothèque en raison d'un bogue critique / d'une faille de sécurité;
• ou juste besoin de vérifier si une faille de sécurité annoncée vous concerne.

De plus, lorsque vous effectuez effectivement une mise à jour, le gestionnaire de packages s'assure (généralement) que toutes les dépendances transitives sont mises à jour si nécessaire.

Alors qu'avec un libdossier, vous avez juste un tas de fichiers (éventuellement binaires, et éventuellement modifiés), et vous devrez deviner d'où ils viennent et quelle version ils sont (ou faire confiance à certains fichiers README, qui peuvent ne pas être corrects ).

Pour aborder vos autres points:

Pas besoin d'outil externe pour gérer les packages.

Certes, mais a) en tant que développeur de logiciels, vous devez de toute façon installer de nombreux outils. Ainsi, un ou plusieurs outils ne sont généralement pas importants, et b) il n’ya généralement qu’un ou plusieurs gestionnaires de packages dans un domaine donné (Maven / Gradle pour Java, npm pour JS / TypeScript, etc.), vous n’avez donc pas besoin d’en installer des dizaines.

Aucune connexion Internet requise pour construire.

Tous les gestionnaires de paquets que je connais travaillent hors ligne, une fois qu'ils ont téléchargé les dépendances requises (ce qui peut se produire juste après le téléchargement du projet lui-même).

Construction plus rapide (pas de vérification de paquet).

Probablement vrai, mais il semble peu probable que la vérification du paquet hors ligne prenne beaucoup de temps (il s'agit simplement de comparer certains numéros de version). Une vérification en ligne peut prendre un certain temps, mais elle peut être désactivée si vous le souhaitez (même si elle est activée par défaut - Maven, par exemple, ne vérifie jamais les mises à jour des versions publiées).

Environnements plus simples (moins de connaissances requises).

Certes, mais comme expliqué ci-dessus, un libdossier nécessite également des connaissances. En outre, comme expliqué ci-dessus, vous ne travaillerez probablement qu'avec une poignée de gestionnaires de paquets différents, que vous connaissez déjà.

Les avantages du dossier lib disparaissent rapidement après le passage d'un développement à petite échelle à un travail plus important.

Par exemple, l'avantage de ne pas faire appel à un outil externe est compensé par le travail requis pour gérer manuellement vos dépendances, de sorte que l'outil sera vous (dans plus d'un sens du monde).

Vous n'avez pas besoin d'une connexion Internet pour un gestionnaire de paquets. Vous pouvez utiliser les référentiels locaux.

Une construction plus rapide peut être vraie, mais ce n’est pas vraiment quelque chose qui devrait déterminer s’il faut ou non utiliser un gestionnaire de paquets. Nous ne parlons pas de grandeurs de différence après tout, et cela dépend aussi de votre configuration. Vous pouvez facilement faire une construction lente en utilisant un gestionnaire de paquets, mais c'est essentiellement du sabotage.

Environnements plus simples (moins de connaissances requises)? Encore une fois, dans le développement à petite échelle est certainement une possibilité. Vous pourrez peut-être garder le projet dans votre tête complètement, jusqu’à chacune des rares bibliothèques utilisées. Ajoutez un simple script de compilation / makefile et vous aurez un package complet.

Mais il n'a pas fait des environnements plus simple, il ne fonctionne que dans des environnements simples. Dans le développement à plus grande échelle, vous serez heureux d'utiliser des outils standard plutôt que des solutions personnalisées. Après tout, vous n’avez qu’à l’apprendre une fois (et lorsque le gestionnaire de paquets du jour est remplacé par le nouveau système sympa, vous devez également l’apprendre).

Vous manquez beaucoup des avantages des gestionnaires de paquets.

1. Les gestionnaires de packages vous permettent d'éviter de contrôler des fichiers binaires volumineux (plusieurs mégaoctets ou plus) dans le contrôle de source. Cela est un anathème pour de nombreux outils de contrôle de source, le git omniprésent en étant l’un d’eux. Il y a quelques mois, un référentiel a atteint les limites de taille de Bit Bucket, car les développeurs vérifiaient CocoaPods. Un autre projet en était déjà à mi-chemin lorsque nous avons migré de SVN, car nous avions vérifié tous nos fichiers binaires de bibliothèque (et n’avions pas utilisé NuGet). Étant donné que les gestionnaires de packages téléchargeront les packages à la volée pour chaque développeur, ils ne nécessiteront plus de vérifier ces fichiers binaires.
2. Ils empêchent de mélanger des fichiers / bibliothèques incompatibles. Les dossiers peuvent contenir des versions mixtes des fichiers de la bibliothèque si quelqu'un ne le nettoie pas correctement lors d'une mise à niveau. J'ai vu un cas où la moitié des fichiers binaires du dossier ont été mis à niveau, ce qui entraîne des bogues très étranges. (Il ne s'est même pas écrasé!) Il nous a fallu littéralement des mois (pas beaucoup d'heures de travail, mais globalement le temps total) pour comprendre le problème. En laissant le gestionnaire de paquets contrôler tout le dossier, vous ne pouvez pas obtenir de versions mixtes; vous assurez la cohérence. Ils rendent également beaucoup plus difficile l’utilisation de dépendances incompatibles , en mettant à jour automatiquement tous les éléments ensemble, en installant différentes versions si nécessaire, ou même en émettant simplement des avertissements ou des erreurs lorsque vous essayez d’utiliser des versions incompatibles de bibliothèques.
3. Ils établissent une convention partagée pour la gestion des bibliothèques. Lorsque de nouveaux développeurs rejoignent votre projet, votre équipe, votre entreprise, etc., ils connaissent probablement les conventions du gestionnaire de paquets. Cela signifie qu'ils ne perdent pas de temps à comprendre les détails de la gestion des bibliothèques dans votre base de code.
4. Ils vous offrent un moyen standard de gestion des versions et de distribution de vos propres dépendances et fichiers qui n'appartiennent pas à votre référentiel. Je les ai même personnellement exploitées pour certains fichiers de données statiques volumineux requis par mon application. Elle fonctionne donc bien pour la gestion de versions en plus du code binaire.
5. Certains gestionnaires de paquets fournissent des fonctionnalités supplémentaires lors de l'installation. NuGet ajoutera des dépendances et des fichiers de contenu à votre fichier csproj et pourra même ajouter des éléments de configuration au fichier de configuration.
6. Leurs fichiers de liste de paquets documentent les versions de vos bibliothèques dans un seul et même endroit centralisé. Je n'ai pas à cliquer avec le bouton droit de la souris sur une DLL et à regarder le numéro de version pour déterminer la version de la bibliothèque que j'utilise. En Python, l'auteur de la bibliothèque n'a peut-être même pas inclus le numéro de version dans les fichiers py. Il est donc possible que je ne puisse même pas en dire la version de la bibliothèque.
7. Ils découragent l'installation de dépendances à l'échelle de la machine. Les gestionnaires de packages constituent un moyen conventionnel d’installer des dépendances sans programme d’installation global . Lorsque vos options sont dossier répertoire et installation globale, de nombreux développeurs de bibliothèques choisiront d’offrir leurs bibliothèques primaires sous forme d’installations globales plutôt que sous forme de fichiers binaires téléchargeables que vous devez configurer vous-même. (L'histoire de MS le prouve. C'est également le cas de nombreuses bibliothèques sous Linux.) Cela rend en réalité la gestion de plusieurs projets plus difficile, car vous pouvez avoir des projets avec des versions en conflit et certains développeurs choisiront certainement l'installation globale apparemment plus simple plutôt que d'avoir leur propre bibliothèque. dir.
8. Ils ont tendance à centraliser l'hébergement et la distribution. Vous n'êtes plus obligé de dépendre du site Web de cette bibliothèque aléatoire. S'ils cessent leurs activités, le site d'un gestionnaire de paquets performant a toujours toutes les versions téléchargées. Les développeurs n'ont pas non plus à traquer beaucoup de sites Web uniquement pour télécharger de nouvelles bibliothèques; ils ont tout ce qu'il faut pour regarder en premier et même parcourir différentes options. Il est également plus facile de mettre en miroir des packages organisés de manière standard que d'héberger manuellement des copies de tout contenu à partir de sites Web ad-hoc.

Vous surestimez également la valeur de vos "avantages".

1. Pas besoin d'outil externe pour gérer les packages.

   "Externe" à quoi? Je vérifie l'exécutable NuGet dans mes référentiels. C’est le seul fichier binaire que j’ai le droit d’enregistrer, car il est petit et signifie que je n’ai pas besoin de vérifier d’autres fichiers binaires.

   pip ne pose pas de problème à cet égard, car il est désormais livré avec Python par défaut et les modifications incompatibles en amont et en aval sont extrêmement rares. De toute façon, vous ne développerez pas de code Python sans l'avoir installé à l'extérieur de votre projet.

   Au moment où ils atteignent une adoption généralisée, les gestionnaires de paquets ont tendance à être très stables. Vous ne pouvez pas vous en sortir sans une sorte d’outillage installé globalement pour la plupart des projets, et un gestionnaire de paquets unique est une exigence assez légère. Cela n’est généralement pas beaucoup plus encombrant que d’avoir installé le runtime linguistique.

2. Aucune connexion Internet requise pour construire.

   Je ne peux pas me connecter à ma base de données sans une connexion réseau. Si la base de données est hébergée sur Amazon, il me faut quand même une connexion Internet complète. J'ai besoin d'une connexion Internet pour transmettre et appliquer les modifications via le contrôle de source. un serveur de construction ne peut pas extraire le code pour construire sans une sorte de connexion réseau non plus. Vous ne pouvez pas envoyer ou recevoir de courrier électronique sans un. Vous ne pouvez pas télécharger des bibliothèques pour les mettre dans votre dossier lib sans une! Développer en permanence sans connexion Internet est pratiquement inconnue. Dans de rares cas où cela est nécessaire, vous pouvez résoudre ce problème en téléchargeant les packages dans un emplacement pouvant être utilisé par le gestionnaire de packages. (Je sais que NuGet et pip sont assez contents de tirer d'un simple dossier ou d'un lecteur réseau; je suppose que la plupart des autres peuvent également le faire.)

3. Construction plus rapide (pas de vérification de paquet).

   30 secondes lors de la génération automatisée et 5 secondes lors de la construction de développeurs locaux sont un bon compromis pour les avantages que j'ai décrits ci-dessus. Ce sont des délais triviaux qui ne valent généralement pas la peine d'être considérés par rapport aux problèmes résolus par les avantages.

4. Environnements plus simples (moins de connaissances requises).

   Un outil pour la gestion de paquets contre rien pour la gestion de bibliothèque n'est pas vraiment une comparaison juste, de toute façon. Sans l'outil, vous devez apprendre le processus personnalisé utilisé par le projet.gérer ses bibliothèques. Cela signifie que vous n'êtes jamais sûr que vos connaissances existantes s'appliquent à un nouveau projet que vous approchez. Vous devrez faire face à l’approche incohérente proposée par quelqu'un ou inventer la vôtre. Cela pourrait être un répertoire contenant toutes les bibliothèques, ou bien quelque chose de beaucoup plus étrange. Peut-être pour éviter d’archiver les bibliothèques, quelqu'un les mettra toutes sur un lecteur réseau et le seul indicateur de version est le nom du dossier. Comment est-ce ou une installation globale vraiment mieux? En comparaison, un gestionnaire de paquets vous donne une convention propre qui s'appliquera à la plupart des projets que vous rencontrerez.

Le thème commun est qu'ils fournissent cohérence, documentation et fonctionnalités non seulement dans les projets, mais même entre eux. Cela simplifie la vie de tous.

Après avoir récemment converti notre produit de l'utilisation de bibliothèques téléchargées manuellement en gestion automatique de paquets avec Nuget, je peux affirmer que l'utilisation d'un gestionnaire de paquets présente des avantages considérables.

Notre produit est implémenté dans 27 projets C #, ce qui est relativement petit par rapport aux normes actuelles. Certaines de nos dépendances de tiers ont des dizaines d'assemblées.

Avant Nuget, si je voulais mettre à jour toutes nos dépendances avec la dernière version, je devais:

1. Repérer où je pourrais obtenir toutes les bibliothèques mises à jour
2. Téléchargez-les et décompressez / installez
3. Ajouter les nouvelles versions au contrôle de source
4. Parcourez manuellement toutes les références de nos projets et mettez-les à jour pour qu'elles pointent vers les nouveaux assemblages.

Avec 27 projets et des dizaines d'assemblys de dépendance, ce processus était très sujet aux erreurs et pouvait prendre des heures.

Maintenant que nous avons mis à jour l'utilisation de Nuget, tout est fait pour moi avec une seule commande.

Pas besoin d'outil externe pour gérer les paquets

C'est un peu un non-point, n'est-ce pas? Si j'utilise un gestionnaire de paquets, je n'ai pas besoin d'un dossier lib. Je n'ai pas non plus à gérer les paquets moi-même.

Aucune connexion Internet requise pour construire

Mis à part le fait qu'il est assez rare de ne pas avoir de connexion Internet aujourd'hui pendant le développement (peut-être à l'exception du transit), un bon gestionnaire de paquets ne devrait pas vous obliger à avoir la dernière version pour créer votre application. Cela pourrait se plaindre, mais il n'y a aucune raison de ne pas construire avec la version déjà installée

Construction plus rapide (pas de vérification de paquet)

C'est un speedboost assez marginal, mais vous pouvez sans doute faire valoir un argument à cet égard.

Environnements plus simples (moins de connaissances requises)

La plupart des gestionnaires de paquets sont si simples de nos jours qu'il ne vaut pas la peine d'essayer de les contourner en les faisant. Il y a même des clients visuels si vous le souhaitez. En fait, ils cachent beaucoup de choses qui se passent.

Les gestionnaires de packages vous permettent également de partager ces packages entre différents projets. Si 5 de mes projets utilisent la même version de Boost, il n'est pas nécessaire de le dupliquer pour chaque projet. Cela est particulièrement vrai pour les arbres de dépendance complexes dont vous parlez.

Avec un dossier lib, vous ne gérez les packages que pour ce projet, tandis qu'un gestionnaire de packages vous permet de le faire pour l'ensemble de votre environnement de développement avec un seul outil.

C'est la différence entre simplement utiliser des bibliothèques (répertoire lib) et les utiliser, en maintenant des méta-informations (gestionnaire de paquets) . Ces méta-informations concernent les numéros de version, les dépendances (transitives) entre bibliothèques et autres.

Les discussions sur l'enfer des DLL, la compatibilité des bibliothèques, le système de modules java, OSGi et autres devraient au moins suffire à convaincre de l'intérêt d'une forme de gestion de la dépendance.

• La version de la bibliothèque et les problèmes de dépendance peuvent être une perte de temps.

Un référentiel partagé (local) présente également l'avantage de ne pas obliger plusieurs projets à conserver des copies des bibliothèques importées. Si l'on a un projet avec 20 sous-modules, certains de ces modules ont une quarantaine de dépendances impaires.

• Plus de structure
• Plus de rognage des bibliothèques
• Aucune décision humaine ad-hoc sur les bibliothèques

Dans certains cas, un dossier lib peut être nécessaire, par exemple lorsqu'il s'agit de bibliothèques obsolètes (une version de celui-ci n'est plus maintenue / disponible), une version modifiée localement d'une bibliothèque, ...

Mais pour tout le reste, c'est comme si le développeur assumait le rôle du gestionnaire de paquets:

• Le développeur devra télécharger les bibliothèques (Internet requis)
• Le développeur devra vérifier manuellement les nouvelles versions
• ...

Et à mon humble avis, il faut moins de connaissances, car vous devez en apprendre davantage sur l’utilisation de l’outil externe, mais moins sur les bibliothèques (c’est-à-dire les dépendances).

Il existe un autre problème qui n’est pas couvert par d’autres questions: le partage des dépenses.

Disons que vous avez deux paquets construisant la même bibliothèque. Dans le meilleur des cas, il n'y aura pas de coflicts, mais le même espace disque dur / SSD utilisé deux fois. Dans le pire des cas, il y aura des conflits variés, comme des versions.

Si vous utilisez le gestionnaire de packages, la bibliothèque ne sera installée qu'une seule fois (par version) et fournira déjà son chemin d'accès.

PS: bien sûr, vous avez besoin d’un couplage dynamique (ou d’une fonction similaire dans votre langue) pour obtenir ce pro.

L'une des principales raisons pour lesquelles les bibliothèques partagées ont été considérées comme un élément de progrès dans les systèmes Unix et Windows des années 90 était la façon dont ils pouvaient réduire l'utilisation de la RAM lorsque plusieurs programmes utilisant le même ensemble de bibliothèques étaient chargés. L'espace de code ne doit être alloué qu'une fois par bibliothèque et version précises de cette bibliothèque . La seule utilisation restante de la mémoire par instance concerne les variables statiques.

De nombreux systèmes d'exploitation implémentent des bibliothèques partagées d'une manière qui dépend de mécanismes tels que l'unix mmap () api - ce qui implique qu'une bibliothèque ne doit pas seulement être exactement la même version mais en réalité, le même FICHIER. Il est tout simplement impossible d'en tirer pleinement parti pour un programme contenant ses propres bibliothèques.

Étant donné que la mémoire est bien moins chère et que les versions de bibliothèque nécessitent une plus grande diversité que dans les années 90, cet argument n'a pas autant de poids aujourd'hui.