Maintenir un Gemfile.lock cohérent pour une gemme avec des extensions natives

Question

Je travaille dans une équipe d'ingénieurs qui développe une gemme avec des exécutables natifs. Pour des raisons contractuelles, il est important que lorsque nous déployons dans un nouvel environnement, toutes les dépendances utilisent les mêmes versions exactes que celles que nous avons testées. Le Gemfile peut uniquement gérer des versions de dépendances de premier ordre, et non des versions récursives. Pour cette raison, nous avons historiquement gardé notre fichier de verrouillage vérifié dans github, mais cela nous a empêché de mettre à jour bundler depuis la version 1.14. Le problème est que nous avons des machines de développement qui sont à la fois Mac OS X et Linux, et à partir de 1,14, le début de la lockfile dans le dépôt de bijou changé de:

PATH 
    remote: . 
    specs: 
    engine (21.2.13) 
     <gemspec dependencies here> 

à

PATH 
    remote: . 
    specs: 
    engine (21.2.13-x86_64-linux) 
     <gemspec dependencies here> 

C'est problème parce que quand un développeur tire le repo sur OSX et exécute bundle install, il va changer le contenu du fichier de verrouillage. Ensuite, quand un développeur Linux fait la même chose, il va changer à nouveau, créant un tas de changements dans l'histoire git du fichier de verrouillage!

J'ai essayé d'exécuter bundle lock --add-platform x86_64-linux et bundle lock --add-platform x86_64-darwin, en espérant que cela convaincrrait bundler de maintenir deux entrées pour les différentes plates-formes, au lieu de flip flopping entre eux. Il a produit des entrées en double pour certaines des gemmes dans la section GEM du fichier de verrouillage, mais pas pour celle de la section PATH\n specs:.

Actuellement, notre Gemfile contient la ligne:

gemspec name: "engine" 

qui charge engine.gemspec. Ce fichier contient:

Gem::Specification.new do |spec| 
    ... 
    spec.platform = Gem::Platform::CURRENT 
    ... 
end 

que je suspecte être le problème. J'ai essayé d'inclure le gemspec deux fois dans le Gemfile, et en utilisant une variable globale pour spécifier la plate-forme à utiliser, mais bundler ne le charge que la première fois, et saute la deuxième tentative.

Est-ce que quelqu'un sait d'une solution qui nous permettra de garder les deux versions de gemme spécifiques à la plate-forme dans le même fichier de verrouillage?

Ou sinon, existe-t-il un moyen de désactiver le comportement new-ish du bundler qui ajoute le nom de la plate-forme à la version gem? Dans le passé, lorsque le fichier de verrouillage spécifiait simplement "21.2.13" et que notre serveur gemserver contenait deux copies de chaque version (avec des binaires construits pour les deux plates-formes), bundler n'a jamais eu de problèmes pour résoudre la version correcte. comme le fichier de verrouillage stockant des informations superflues. Puis-je en quelque sorte lui dire d'arrêter?

Answer 1

J'avais entendu dire qu'il était recommandé et non recommandé d'avoir votre fichier de verrouillage dans le contrôle de version, mais jamais entièrement compris les raisons. Cela semble avoir été la source du problème!

La recommandation que je vois le plus souvent (même si cela ne peut pas toujours être possible), c'est que le fichier de verrouillage ne devrait jamais être sous contrôle de version pour une gemme, mais toujours pour une application autonome. L'idée est qu'une gemme est destinée à être portable, et devrait donc avoir une certaine flexibilité dans ses dépendances. Fait important, cette flexibilité n'empêche pas notre environnement de développement d'être cohérent, à condition que tous les tests ne se déroulent pas dans le référentiel gem mais dans le référentiel de l'application autonome qui utilise la gemme.

Le fichier de verrouillage de cette application autonome dépiste déjà les dépendances que nous croyions utiliser le fichier verrou de la gem pour le suivi, et lorsque l'application est déployée, toutes les dépendances de la gemme sont fixées à l'intérieur de l'application. La section "spec" du Gemfile.lock ne doit être présente que dans un dépôt de gemme, et le fait que cette section nomme les gemmes dépendantes de la plate-forme n'est pas un problème, car la gemme est référencée par une plate-forme indépendante nom dans le fichier de verrouillage de l'application qui l'utilise.