Pourquoi préférer un gestionnaire de packages à 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 packages, j'ai l'impression que le dossier de bibliothèque est une meilleure approche.
Avantages que je vois avec un dossier de bibliothèque:
- Pas besoin d'un outil externe pour gérer les packages.
- Aucune connexion Internet requise pour construire.
- Construction plus rapide (pas de vérification de paquet).
- Environnement plus simple (moins de connaissances requises).
Je vois avec un gestionnaire de paquets:
- Aide avec des arbres de dépendances complexes (et qui peuvent être gérés en téléchargeant une dépendance avec toutes ses dépendances).
- 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 que je manque?
Un point important qui manque aux autres réponses:
Utiliser un gestionnaire de packages signifie avoir une configuration qui indique quelles versions de bibliothèques vous utilisez et s'assure que les informations de configuration sont réellement correctes.
Savoir quelles bibliothèques vous utilisez et quelle version est très important si vous:
- besoin de mettre à jour une bibliothèque en raison d'un bug critique/trou de sécurité;
- ou juste besoin de vérifier si une faille de sécurité annoncée vous affecte.
De plus, lorsque vous effectuez une mise à jour, le gestionnaire de packages s'assure (généralement) que toutes les dépendances transitives sont mises à jour selon les besoins.
Alors qu'avec un dossier lib, vous avez juste un tas de fichiers (éventuellement binaires, et éventuellement modifiés), et vous devrez deviner d'où ils viennent et de quelle version ils sont (ou faire confiance à un README, qui peut ou peut ne pas être correct).
Pour aborder vos autres points:
Pas besoin d'outils externes pour gérer les packages.
Certes, mais a) en tant que développeur de logiciels, vous devez quand même installer de nombreux outils, donc un de plus n'a généralement pas d'importance, et b) il n'y a généralement qu'un ou quelques gestionnaires de packages dans un domaine donné (Maven/Gradle pour Java, npm pour JS/TypeScript, etc.), ce n'est donc pas comme si vous deviez en installer des dizaines.
Aucune connexion Internet requise pour construire.
Tous les gestionnaires de packages 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 package 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 (si elle est même activée par défaut - Maven, par exemple, ne vérifie jamais les mises à jour des versions).
Environnements plus simples (moins de connaissances requises).
Certes, mais comme expliqué ci-dessus, un dossier lib nécessite également des connaissances. De plus, comme expliqué ci-dessus, vous ne travaillerez probablement qu'avec quelques gestionnaires de packages 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, le "bénéfice" de ne pas avoir besoin d'un outil externe est contrebalancé par le travail requis pour gérer manuellement vos dépendances, donc 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 des référentiels locaux.
Une construction plus rapide peut être vraie, mais ce n'est pas quelque chose qui devrait déterminer s'il faut utiliser un gestionnaire de packages ou non. Nous ne parlons pas d'amplitudes 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, 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 makefile/autre script de construction et vous obtenez un package complet.
Mais ce n'est pas rendre les environnements plus simples, cela ne fonctionne que dans des environnements simples. Dans le développement à plus grande échelle, vous serez heureux d'utiliser des outils standard au lieu de solutions personnalisées. Après tout, vous ne devez l'apprendre qu'une seule fois (et lorsque le gestionnaire de paquets du jour est remplacé par le nouveau truc cool, vous devez aussi l'apprendre).
Vous manquez beaucoup des avantages des gestionnaires de paquets.
- Les gestionnaires de packages vous permettent d'éviter d'insérer de gros binaires (plusieurs mégaoctets ou plus) dans le contrôle de code source. Cela est anathème pour de nombreux outils de contrôle de code source, le git omniprésent étant l'un d'entre eux. Il y a quelques mois, un référentiel a atteint les limites de taille de Bit Bucket parce que les développeurs archivaient CocoaPods. Un autre projet était déjà à mi-chemin lorsque nous avons migré de SVN parce que nous avions archivé tous nos binaires lib (et n'avions pas utilisé NuGet). Étant donné que les gestionnaires de packages téléchargeront des packages à la volée pour chaque développeur, ils éliminent la nécessité d’archiver ces fichiers binaires.
- Ils empêchent le mélange de fichiers/bibliothèques incompatibles. Les dossiers peuvent contenir des versions mixtes des fichiers de la bibliothèque si quelqu'un ne les nettoie pas correctement lors d'une mise à niveau. J'ai vu un cas où la moitié des fichiers binaires dans le dossier ont été mis à niveau, ce qui entraîne des bugs très étranges. (Il n'a même pas planté!) Il nous a fallu littéralement des mois (pas des heures de travail, juste du temps global) pour comprendre le problème. En laissant le gestionnaire de packages contrôler l'ensemble du 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 tout ensemble, en installant différentes versions si nécessaire, ou même en lançant simplement des avertissements ou des erreurs lors de la tentative pour utiliser des versions incompatibles de bibliothèques.
- Ils établissent une convention partagée pour la gestion des bibliothèques. Lorsque de nouveaux développeurs arrivent sur votre projet, équipe, entreprise, etc., ils 'est susceptible de connaître les conventions du gestionnaire de paquets. Cela signifie qu'ils n'ont pas à perdre de temps à trouver les détails de la gestion des bibliothèques dans votre base de code.
- Ils vous donnent un moyen standard de versionner et de distribuer vos propres dépendances et fichiers qui n'appartiennent pas à votre référentiel. Je les ai même personnellement utilisés pour certains gros fichiers de données statiques requis par mon application, donc cela fonctionne bien pour versionner des choses en plus du code binaire.
- Certains gestionnaires de packages fournissent des fonctionnalités supplémentaires lors de l'installation. NuGet ajoutera des dépendances et des fichiers de contenu à votre fichier csproj et peut même ajouter des éléments de configuration au fichier de configuration.
- Leurs fichiers de liste de paquets documentent les versions de vos bibliothèques en un seul endroit centralisé. Je n'ai pas à cliquer avec le bouton droit sur un DLL et regarder le numéro de version pour comprendre quelle version de la bibliothè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, donc je ne pourrai peut-être même pas en dire la version.
- Ils découragent l'installation à l'échelle de la machine des dépendances. Les gestionnaires de packages fournissent une manière conventionnelle d'installer les dépendances sans programme d'installation global . Lorsque vos options sont le dossier lib et l'installation globale, de nombreux développeurs de bibliothèques choisiront d'offrir leurs bibliothèques primaires en tant qu'installations globales plutôt qu'en tant que fichiers binaires téléchargeables que vous devez configurer vous-même. (L'histoire de MS le démontre. C'est également le cas pour de nombreuses bibliothèques sous Linux.) Cela rend en fait la gestion de plusieurs projets plus difficile, car vous pouvez avoir des projets avec des versions conflictuelles et certains développeurs choisiront certainement l'installation globale apparemment plus simple que d'avoir leur propre lib dir.
- Ils ont tendance à centraliser l'hébergement et la distribution. Vous n'avez plus à dépendre du site Web de cette bibliothèque aléatoire. S'ils cessent leurs activités, le site d'un gestionnaire de packages performant a toujours toutes les versions téléchargées. Les développeurs n'ont pas non plus à traquer de nombreux sites Web simplement pour télécharger de nouvelles bibliothèques; ils ont un endroit incontournable 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 à partir de sites Web ad hoc.
Vous surestimez également la valeur de vos "avantages".
Pas besoin d'outils externes pour gérer les packages.
"Externe" à quoi? Je vérifie l'exécutable NuGet dans mes référentiels. C'est le seul binaire pour lequel je me sens bien à l'enregistrement, car il est petit et signifie que je n'ai pas besoin d'archiver d'autres binaires.
pip ne pose pas de problème sur ce front car il est fourni avec Python par défaut maintenant et les modifications incompatibles et inverses sont extrêmement rares. Vous n'allez pas développer Python code sans avoir Python installé en externe à votre projet, de toute façon.
Au moment où ils atteignent une adoption généralisée, les gestionnaires de packages ont tendance à être très stables. Vous ne pouvez pas vous en tirer sans certains types d'outils installés globalement pour la plupart des projets, et un seul gestionnaire de packages est une exigence assez légère. Ce n'est généralement pas beaucoup plus lourd que d'avoir le runtime de langue installé.
Aucune connexion Internet requise pour construire.
Je ne peux pas me connecter à ma base de données sans connexion réseau. Si la base de données est hébergée sur Amazon, j'ai quand même besoin d'une connexion Internet complète. J'ai besoin d'une connexion Internet pour pousser et tirer les modifications via le contrôle de code source; un serveur de build ne peut pas non plus extraire le code à construire sans une sorte de connexion réseau. Vous ne pouvez pas envoyer ou recevoir des e-mails sans un. Vous ne pouvez pas télécharger de bibliothèques pour les mettre dans votre dossier lib sans en avoir une! Le développement permanent sans connexion Internet est pratiquement inconnu. Dans certains cas rares où cela est nécessaire, vous pouvez résoudre ce problème en téléchargeant les packages à un emplacement que le gestionnaire de packages peut utiliser. (Je sais que NuGet et pip sont très heureux de tirer d'un simple dossier ou lecteur réseau; je soupçonne que la plupart des autres le peuvent aussi.)
Construction plus rapide (pas de vérification de paquet).
30 secondes pendant la construction automatisée et 5 secondes pendant les versions de développement locales 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 même pas la peine d'être pris en considération par rapport aux problèmes que les avantages résolvent.
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 quel que soit le processus personnalisé que le projet utilise pour gérer ses bibliothèques. Cela signifie que vous n'êtes jamais sûr que vos connaissances existantes s'appliquent à tout nouveau projet que vous approchez. Vous devrez faire face à toute approche de méli-mélo que quelqu'un a imaginée ou inventer la vôtre. Ce pourrait être un répertoire contenant toutes les bibliothèques, ou ce pourrait être quelque chose de beaucoup plus étrange. Peut-être pour éviter d'archiver les bibliothèques, quelqu'un les a toutes sorties sur un lecteur réseau et le seul indicateur de version est le nom du dossier. Comment est-ce vraiment mieux ou une installation globale? Par comparaison, un gestionnaire de packages vous donne une convention claire qui s'appliquera à la plupart des projets que vous rencontrez.
Le thème commun est qu'ils fournissent de la cohérence, de la documentation et des fonctionnalités non seulement au sein des projets, mais même entre eux. Cela simplifie la vie de chacun.
Ayant récemment converti notre produit de l'utilisation de bibliothèques téléchargées manuellement en gestion automatique de packages avec Nuget, je peux dire que l'utilisation d'un gestionnaire de packages présente d'énormes avantages.
Notre produit est implémenté dans 27 projets C #, ce qui est relativement petit par rapport aux normes actuelles. Certaines de nos dépendances tierces ont des dizaines d'assemblys.
Avant Nuget, si je voulais mettre à jour toutes nos dépendances vers la dernière version, je devrais:
- Trouvez où je pourrais obtenir toutes les bibliothèques mises à jour
- Téléchargez-les et décompressez/installez
- Ajouter les nouvelles versions au contrôle de code source
- Parcourez manuellement toutes les références de nos projets et mettez-les à jour pour pointer vers les nouveaux assemblages
Avec 27 projets et des dizaines d'assemblys de dépendances, ce processus était très sujet aux erreurs et pouvait prendre des heures.
Maintenant que nous avons mis à jour Nuget, tout est fait pour moi avec une seule commande.
Pas besoin d'outils externes pour gérer les packages
C'est une sorte de flou, n'est-ce pas? Si j'utilise un gestionnaire de paquets, je n'ai pas besoin d'avoir un dossier lib. Je n'ai pas non plus à gérer les packages moi-même.
Aucune connexion Internet requise pour construire
Mis à part le fait de ne pas avoir de connexion Internet aujourd'hui pendant le développement est quelque peu rare (peut-être à l'exception d'être en transit), un gestionnaire de paquets décent ne devrait pas vous obliger à avoir la dernière version pour construire votre application. Il pourrait se plaindre, mais il n'y a aucune raison de ne pas construire avec la version qu'il a 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 point pour cela.
Environnements plus simples (moins de connaissances requises)
La plupart des gestionnaires de paquets sont si simples de nos jours qu'il ne vaut guère la peine d'essayer de les contourner en faisant cela. Il y a même des clients visuels si vous le souhaitez. Ils cachent en fait une grande partie de la croft qui se passe.
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 gérez les packages uniquement 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 les bibliothèques (répertoire lib) , et en les utilisant, en maintenant 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 DLL enfer, compatibilité avec les bibliothèques, Java, OSGi et autres) devraient au moins être suffisamment convaincantes pour justifier une certaine forme de gestion des dépendances .
- La version de la bibliothèque et les problèmes de dépendance peuvent être une perte de temps.
Il existe également l'avantage d'un référentiel partagé (local), de sorte que plusieurs projets n'ont pas besoin de conserver des copies des bibliothèques importées. Si l'on a un projet avec 20 sous-modules, certains de ces modules ont 40 dépendances impaires.
- Plus de structure
- Plus de rognage des bibliothèques
- Aucune décision humaine ad hoc sur les bibliothèques
Il y a des cas où 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 de gestionnaire de packages:
- 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, c'est moins de connaissances requises, 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 y a un autre problème qui n'est pas couvert par d'autres questions: le partage des dep.
Disons que vous avez deux packages construction même bibliothèque. Dans le meilleur des cas, il n'y aura pas de conflit, mais le même espace HDD/SSD utilisé deux fois. Dans le pire des cas, il y aura des conflits varios, comme les versions.
Si vous utilisez le gestionnaire de packages, il n'installera la bibliothèque qu'une seule fois (par version) et lui fournira déjà un chemin d'accès.
P.S .: bien sûr, vous avez besoin d'une liaison dynamique (ou d'une fonction similaire dans votre langue) pour obtenir ce pro.