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

68

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?

Ignacio Soler Garcia
la source
33
Je pense que vous vous interrogez vraiment sur les avantages du groupement par rapport à l’ exigence de bibliothèques. Vous obtiendrez des réponses plus pertinentes si vous utilisez ces termes.
Kilian Foth le
3
Qu'est-ce qui vous empêche de créer un conteneur de menu fixe pour l'agent de génération, contenant tout ce dont vous avez besoin et n'autorisant peut-être même pas l'accès à Internet (cela ne devrait pas être nécessaire pour la construction)? Je pense que vous êtes plus contre l’acquisition d’un nouvel outil que la prise en compte d’arguments. Avez-vous déjà travaillé sur un grand projet utilisant des dépendances gérées manuellement? Ce n'est pas aussi génial que vous le donnez.
Kayaman
3
@Kayaman: apprendre un nouvel outil coûte du temps (d'argent) à l'équipe et j'aimerais vérifier que nous l'investissons correctement. Mon expérience avec les grands projets est que les dépendances sont assez stables (elles ne changent presque jamais) et c'est peut-être pourquoi un gestionnaire de paquets me semble cher. Quoi qu'il en soit, je ne faisais qu'énumérer les avantages et les inconvénients après avoir travaillé pendant un certain temps avec Nuget et passé du temps avec lui.
Ignacio Soler Garcia
2
@sebkur Vous pouvez conserver des copies locales de tous vos colis. Nous conservons les versions actuelles de toutes nos dépendances sous contrôle de source local. Le gestionnaire de paquets a besoin d'une connexion uniquement lorsque nous effectuons des mises à niveau.
17 du 26
1
@ 17 sur 26: vous n'apprenez pas comment configurer un agent de construction pour installer nuget et l'exécuter sur demande en 10 minutes. Vous ne le faites pas non plus si vous avez un projet multi-solutions où les mêmes projets sont utilisés dans des solutions différentes.
Ignacio Soler Garcia

Réponses:

122

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à.

sleske
la source
171
“Pas besoin d'outils externes pour gérer les paquets” - ouais. Maintenant, c'est le travail de votre cerveau. Bonne chance, cerveau!
Paul D. Waite
58
Toute personne qui pense sérieusement qu’avoir un dossier lib est un "environnement plus facile" doit simplement essayer de comprendre l’arbre de dépendance pour le nuget Microsoft.AspNetCore.All . Allez, n'attends pas, je vérifierai dans environ un jour.
Voo le
14
En outre, le navigateur Internet que vous utilisez pour rechercher manuellement les bibliothèques est considéré comme un outil externe de gestion des packages. Avec tout ce que vous utilisez (gestionnaire de fichiers du système d'exploitation, etc.) pour préparer et positionner les bibliothèques. Le véritable choix est donc un outil externe (gestionnaire de paquets) contre plusieurs.
NemesisX00
3
Juste pour votre information, j'ai récemment essayé de travailler avec Gradle sur un PC hors ligne. Pas de chance, Android Studio ne lance pas mon application et je reçois un message d'erreur obscur. C'est après avoir effectué une première exécution en ligne pour les dépendances. Ce n'est que dans ce type de situation que l'on s'aperçoit vraiment à quel point la dépendance aux gestionnaires de paquets pour créer des logiciels est devenue ...
FRob
8
@ PaulD.Waite Pendant que nous y étions, nous nous sommes débarrassés de ces "langages" embêtants dont tout le monde parle. De toute façon, tout se résume à un code machine, de sorte que dans mon entreprise, nous avons éliminé l’intermédiaire. Voilà l'efficacité!
CorsiKa
40

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).

Kayaman
la source
21
@ IgnacioSolerGarcia: Ce n'est que plus facile si rien ne se passe mal. Que faire si la nouvelle version de la bibliothèque A nécessite également une mise à jour B et C? Que se passe-t-il si vous l'exécutez toujours, mais introduit des bugs subtils? Cela fait partie de la "gestion des dépendances".
Sleske
18
@ IgnacioSolerGarcia dire "télécharger un fichier" ne donne pas une image exacte. Disons "téléchargez 20 fichiers et assurez-vous que leurs versions sont compatibles". Aucun travail évité là-bas. La mise à jour de paquets n'est pas non plus une situation théorique, à moins que vous n'ayez décidé de geler les versions de dépendance et que vous soyez prêt à accepter les problèmes éventuels (bogues, failles de sécurité) qui en résultent.
Kayaman
12
@ IgnacioSolerGarcia "télécharger un fichier" - voulez-vous dire (1) trouvez le site Web du projet correct (certains sont hébergés sur github, d'autres sur Sourceforge, d'autres sur leurs propres sites Web), (2) allez à la page de téléchargement, (3) trouvez la bonne version , (4) télécharger, (5) décompresser et déposer quelque part. Cela semble beaucoup plus de travail que blah install libfoo. Et puis, multipliez cela par, disons, 5 dépendances.
el.pescado
5
@ IgnacioSolerGarcia Ok quels fichiers dois-je "simplement" télécharger pour que cette nuget fonctionne correctement? Et c’est fondamentalement la configuration la plus simple pour un projet ASP.NET Core. En pratique, vous aurez beaucoup plus de dépendances.
Voo le
6
@ Ignacio C'est le méta-nuget de base pour obtenir l'application ASP.Net Core la plus simple possible. Il était vrai qu'au bon vieux temps du framework complet, tout était "plus facile", car vous veniez de recevoir de grandes bibliothèques monolithiques versionnées en même temps et la publication d'une mise à jour vous prenait des années. Ce modèle a été fondamentalement déconseillé pour de très bonnes raisons, pas seulement dans le monde .NET. Vous devrez vous habituer à tout le modèle de nombreuses petites bibliothèques qui font une chose en particulier et utiliser honnêtement un gestionnaire de paquets est la partie la plus facile de la transition.
Voo le
35

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.

jpmc26
la source
10
"Développer en permanence sans connexion Internet est pratiquement inconnue" J'aurais aimé ne pas savoir mieux. De nombreux développements sont réalisés sur des réseaux complètement séparés pour des raisons de sécurité. Oui, c'est à peu près aussi amusant que cela puisse paraître, mais c'est absolument faisable. Vous devez juste configurer votre propre infrastructure pour le stockage de paquets (c'est-à-dire votre propre flux de pépites).
Voo le
1
Avoir votre propre infrastructure est en fait l’un des rares éléments qui ont du sens dans tous les cas: vous ne voulez pas être fiable sur une infrastructure externe. Si celui-ci n'est pas disponible pour une raison ou une autre, il est préférable d'avoir une solution de repli garantissant que vos développeurs peuvent continuer à se développer. (Et avant que quiconque ne me dise comment ce nuget.org ou npm ou <insérer son dépôt favori> n'aurait jamais de tels problèmes, peut - être réfléchissez-y à nouveau .)
Voo
3
@IgnacioSolerGarcia Mettre en place une convention par projet, par département ou par entreprise n'est pas mieux que de simplement organiser une convention que tout le monde sait sans qu'on le lui dise. En outre, la gestion des packages permet de mieux appliquer la convention, car cela simplifie l' application de la convention plutôt que sa violation. De plus, comme je l'ai mentionné, je commets NuGet directement et l'invoque dans le script de génération, de sorte que je n'ai pas besoin de l'installer. Je garde les installations de serveur de construction à un strict minimum.
jpmc26
2
@ jpmc26 Mon premier accent serait mis sur votre première liste numérotée .
Søren D. Ptæus
1
@ SørenD.Ptæus Fait.
jpmc26
16

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.

17 sur 26
la source
D'accord, c'est le point 2 de la pro. Quoi qu'il en soit, changer de dépendance est quelque chose que nous faisons rarement (probablement à cause du manque de tests de régression automatiques appropriés).
Ignacio Soler Garcia
9
Mettre à jour les dépendances est beaucoup moins pénible si vous le faites régulièrement.
17 du 26
1
Ces tests sont-ils automatisés? Exactement combien de temps prennent-ils pour courir? Même s'il faut 24 heures pour exécuter la suite complète de tests, cela vous permet néanmoins de mettre à jour les dépendances tous les quelques jours avec peu d'inconvénients (même si vous ne le feriez probablement pas aussi souvent dans la pratique). Même si elles sont manuelles et inévitables, vous pourriez passer plusieurs jours à effectuer des tests avec une installation manuelle pour vous rendre compte qu'ils échouaient parce que vous aviez oublié une dépendance d'une dépendance. Vous devez alors recommencer après l'installation, ce qui ne se produirait pas. en utilisant la gestion de paquets ...
Sean Burton
3
N'avez-vous pas besoin de tests de régression sur les nouvelles versions de logiciel? Il suffit de mettre à jour les dépendances lorsque vous êtes déjà en train de tester une version.
17 du 26
4
"Nous ne les avons pas entièrement automatisés et l'outil est trop volumineux pour le faire (cela pourrait prendre des mois pour le tester ou l'automatiser)" - voilà votre gros problème. Ces tests devraient être en place depuis le début. Votre problème n'est pas que l'utilisation de gestionnaires de paquets n'apporte aucun avantage, votre problème est que le contexte dans lequel vous travaillez est trop fragmenté pour que vous puissiez en profiter.
Ant P
14

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.

Athos vk
la source
Il n'est pas si facile de configurer un agent de construction pour installer un gestionnaire de paquets lors d'une construction, pour restaurer des dépendances, etc. Rien de nécessaire avec un dossier lib.
Ignacio Soler Garcia
4
Je pense que cela dépend de la / des langue (s) que vous utilisez. Avec des langages comme Ruby ou Rust, la gestion des paquets est si bien intégrée que l’utiliser est tout à fait trivial.
Sean Burton
Eh bien, je l'ai volontairement fait exprès pour avoir des commentaires plus larges, mais je parle spécifiquement de NuGet, C # et VSTS cloud.
Ignacio Soler Garcia
4
@ Ignacio Quel que soit le système de construction que vous utilisez, la restauration de NuGets ne doit pas être totalement triviale. Elle doit être immédiatement supprimée. Heureusement, VSTS simplifie la tâche ( documentation ): il existe une tâche de restauration NuGet que vous pointez sur votre fichier de solution et indiquez les sources à utiliser - un simple projet nuget.orgfera très bien l'affaire (le modèle par défaut devrait déjà mis en place de cette manière).
Voo le
3
@Ben RVM n'est pas un gestionnaire de paquets. Le gestionnaire de paquets pour Ruby est RubyGems. RVM gère les versions de Ruby lui-même, et pour cela rbenv est meilleur ...
Sean Burton
5

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
Joop Eggen
la source
3

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).

FranMowinckel
la source
4
Même pour les bibliothèques obsolètes ou modifiées, tous les gestionnaires de paquets que j'ai vus jusqu'à présent offrent la possibilité de télécharger des dépendances locales vers votre référentiel local. Mais bon, c’est là que vous perdez une partie de l’expérience "cela fonctionne automatiquement".
Hulk
@ Hulk s'il s'agit d'une bibliothèque open source, vous pouvez (et devriez probablement) simplement publier votre version et ainsi la rendre visible pour le gestionnaire de paquets. Soit en transmettant les modifications aux responsables, soit en apportant votre propre fork de la bibliothèque.
gauche du
Si vous avez modifié une bibliothèque dont le responsable ne répond pas au correctif courrier, il vous reste alors à déterminer comment configurer le gestionnaire de paquets de manière à ce que d'autres paquets dépendant de la bibliothèque puissent également être satisfaits de votre bibliothèque modifiée.
Damian Yerrick
1

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.

val
la source
-5

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.

rackandboneman
la source
4
Cette question ne parle pas de bibliothèques partagées mais de dépendances sur un dossier de bibliothèque.
Ignacio Soler Garcia
1
Cela ne répond pas à la question du PO
esoterik