2010-11-22 11 views
31

Il existe un modèle commun:Comment personnaliser Gemfile par développeur?

De nombreux développeurs travaillent sur un projet et le Gemfile (.lock) est partagé via SCM. Mais que se passe-t-il si certains développeurs veulent utiliser différents outils de test et de développement? Comment faire? Le problème est que lorsque vous placez des sections conditionnelles dans votre Gemfile, le Gemfile.lock sera différent pour chaque développeur et par conséquent vous aurez des conflits chaque fois que vous commettez SCM.

Existe-t-il une solution simple et largement reconnue?

+3

Je suis heureux d'entendre ce n'est pas seulement moi qui est ennuyé par Bundler .. –

+0

En fait, je Je ne suis pas vraiment contrarié par cela;], plus au contraire, mais il s'agit d'une technologie assez jeune et sa documentation n'est pas très détaillée (en plus des options pas si riches) – Jakub

+1

le problème reste à Gemfile.lock, les docs rvm le recommandent ... donc peut-être ignorer localement serait une solution temporaire –

Répondre

0

Chaque développeur peut créer sa propre branche - Bundler fonctionne correctement avec différentes branches ayant des contenus Gemfile différents. C'est une bonne idée pour les développeurs de préfixer les noms de branches avec leurs initiales, pour éviter la confusion ou les collisions.

+4

Créer des succursales pour contourner un oubli dans Bundler? Yuck. Je sais que l'embranchement dans Git est bon marché, mais c'est encore un frais supplémentaire. –

+1

J'appellerais cela plutôt un anti-modèle d'utilisation SCM - désolé de le dire. – Jakub

+0

Ce n'est pas un oubli de Bundler. L'idée derrière Bundler est de geler toutes les dépendances pour que tout le monde ait le même environnement! – rubiii

3

Si vous cochez quelque chose qui dépend d'une gemme, cette gemme devrait se trouver dans le gemfile. Si le code dans le référentiel ne dépend pas d'un gem, il n'est pas nécessaire de l'avoir dans le gemfile. Donc, à moins que vos développeurs ne vérifient pas leurs tests (ce qui serait bizarre) vous auriez besoin de toutes les dépendances du test si vous voulez quand même exécuter toute la suite de tests.

Si les gemmes ne sont pas nécessaires pour exécuter l'application ou ses tests, les gemmes n'ont pas besoin d'être dans le gemfile. Demandez à chaque développeur de créer un gemset (je suppose que vous utilisez RVM, si ce n'est pas le cas) pour l'application et installez tout ce dont ils ont besoin, puis ajoutez simplement ce que l'application doit exécuter dans le gemfile.

+2

Et si les développeurs utilisaient des moteurs de base de données différents en développement? –

+1

Pourquoi voudraient-ils faire ça? Tout le monde a ses préférences mais il faut être pragmatique. –

+0

@ user438962 Il existe plusieurs raisons de préférer sqlite sur postgres dans certains cas - principalement, la facilité d'utilisation –

18

J'aime avoir dans mon Gemfile:

local_gemfile = File.dirname(__FILE__) + "/Gemfile.local" 
if File.file?(local_gemfile) 
    require local_gemfile 
end 

J'ai aussi Gemfile.local et Gemfile.lock à gitignore. Je sais que je ne suis pas "censé", mais je ne pense pas que les mises en garde (comme celles que vous mentionnez dans votre question) en valent la peine.

Mise à jour pour Bundler 1.0.10 du 3 Mars, 2011

local_gemfile = File.dirname(__FILE__) + "/Gemfile.local.rb" 
if File.file?(local_gemfile) 
    self.instance_eval(Bundler.read_file(local_gemfile)) 
end 

je devais utiliser avec Rails 3 et Bundler 1.0.10.

+0

/home/jake/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:29:in 'gem_original_require ': aucun fichier de ce type à charger -/home/jake/code/fullstop/Gemfile.local (LoadError) – jakeonrails

+2

Que faites-vous concernant vos fichiers Gemfile.lock? J'ai essayé de déployer cela dans mon organisation, mais j'ai réalisé que cela changerait entre les agences de développement. –

+0

Suis-je le seul pour qui cela échoue en poussant à Heroku? (se plaint d'une divergence entre Gemfile et Gemfile.serrure) – user456584

-1

(essentiellement la même idée que dans le commentaire Août Lilleaas: gitignore)

Mettez la valeur par défaut/Gemfile minimale dans SCM et ensuite les développeurs changent sur leurs systèmes et de ne jamais commettre. Demandez-leur de l'ajouter à leur changeset inactif dans leur client SVN (s'ils en utilisent un), les autres SCM devraient avoir quelque chose de similaire.

Voici comment nous le faisons dans mon entreprise - fonctionne vraiment bien :)

+1

A quiconque a donné le -1, veuillez (toujours) préciser pourquoi. – sscirrus

+0

Merci, sscirrus. –

+2

Cela ne résout pas le problème des fichiers Gemfile.lock différentiels entre les développeurs (qui devraient être archivés, et OP dit qu'ils le font). Les développeurs peuvent valider uniquement certains changements sur Gemfile.lock, mais cela est compliqué. –

2

Vous pouvez utiliser without de Bundler drapeau pour exclure les groupes.

Si vous avez les éléments suivants Gemfile

group :jakubs_testing_tools do 
    gem "rspec" 
    gem "faker" 
end 

Vous pouvez les exclure avec bundle install

$ bundle install --without jakubs_testing_tools 

http://gembundler.com/groups.html

+0

cela semblerait juste mais nous sommes 5 dans l'équipe donc il n'est pas grand - mais c'est bien sûr faisable ... mais qu'en est-il de la Gemfile.lock - comment cela est-il affecté? – Jakub

2

Il ne vous aidera pas en ce moment, mais il y a eu une feature request ouverte pour que Bundler ajoute le support pour un Gemfile.local pour les âges. Il est prévu pour quelque part dans la série 1.x, alors restez à l'écoute.

Si votre problème principal concerne les gammes IRB spécifiques au développeur, il existe plusieurs solutions de contournement dans le problème comments.

+0

[La décision officielle actuelle] (https://github.com/bundler/bundler/issues/183#issuecomment-22037131) est que ce n'est pas pris en charge. Les solutions de contournement que vous liez ou la réponse principale ici sont de bonnes options –

+0

qui craint à cause du problème où votre Gemfile.lock aura toute cette ordure en elle. – patrick