2010-11-22 23 views
31

C'è un motivo comune:Come personalizzare Gemfile per sviluppatore?

ci sono molti sviluppatori che lavorano su un progetto e Gemfile (.lock) è condiviso tramite SCM. Ma cosa succede se alcuni sviluppatori vogliono utilizzare diversi strumenti per test e sviluppo? Come farlo?

Il problema è che quando si mettono le sezioni condizionali sul proprio Gemfile, anche il Gemfile.lock sarà diverso per ogni sviluppatore e quindi si otterrà un conflitto ogni volta che si esegue il commit su SCM.

Esiste una soluzione semplice e ampiamente riconosciuta?

+3

Sono contento di sentire che non è solo a me chi è infastidito da bundler .. –

+0

in realtà, i non sono davvero infastidito da questo;], al contrario, ma è una tecnologia abbastanza giovane e la sua documentazione non è molto dettagliata (più forse opzioni non così ricca) – Jakub

+1

il problema diventa ancora Gemfile.lock, rvm docs consiglia di controllarlo ... quindi forse ignorarlo localmente sarebbe una soluzione temporanea –

risposta

0

Ogni sviluppatore può creare il proprio ramo - Bundler funziona perfettamente con diversi rami con contenuti Gemfile diversi. È una buona idea che gli sviluppatori facciano precedere i nomi dei rami con le loro iniziali, per evitare confusione o collisioni.

+4

Creazione di filiali solo per aggirare una svista in Bundler? Che schifo. So che la ramificazione in Git è economica, ma è comunque un ulteriore sovraccarico. –

+1

Lo chiamerei piuttosto un anti-pattern di utilizzo di SCM - mi spiace dirlo. – Jakub

+0

Non è una svista in Bundler. L'idea alla base di Bundler è di congelare tutte le dipendenze in modo che tutti abbiano lo stesso ambiente! – rubiii

3

Se si archivia qualcosa che dipende da una gemma, la gemma dovrebbe trovarsi nel file gemma. Se il codice nel repository non dipende da una gemma, non è necessario averlo nel gemfile. Quindi, a meno che i tuoi sviluppatori non controllino i loro test (il che sarebbe strano) avresti bisogno di tutte le dipendenze del test se vuoi comunque eseguire l'intera suite di test.

Se le gemme non sono necessarie per eseguire l'app oi relativi test, le gemme non devono necessariamente trovarsi nel file gemma. Fai in modo che ogni sviluppatore crei un gemset (presumo che tu stia utilizzando RVM, se non dovresti) per l'app e installi tutto ciò di cui hanno bisogno, quindi aggiungi solo ciò che l'app deve eseguire sul gemfile.

+2

Cosa succede se gli sviluppatori stanno utilizzando diversi motori di database in fase di sviluppo? –

+1

Perché dovrebbero farlo? Ognuno ha le sue preferenze, ma devi essere pragmatico. –

+0

@ user438962 ci sono vari motivi per preferire sqlite su postgres in alcuni casi - principalmente, facilità d'uso –

18

mi piace avere questo nel mio Gemfile:

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

Ho anche Gemfile.local e Gemfile.lock in gitignore. So che non sono "supposto", ma non credo che gli avvertimenti (come quelli che hai citato nella tua domanda) valgano la pena.

aggiornamento per Bundler 1.0.10 a partire dal 3 marzo, 2011

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

ho dovuto usare questo con Rails 3 e 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 ': nessun file da caricare -/home/jake/code/fullstop/Gemfile.local (LoadError) – jakeonrails

+2

Cosa fai riguardo ai tuoi file Gemfile.lock? Ho provato a implementarlo nella mia organizzazione, ma ho realizzato che sarebbe cambiato tra i rami degli sviluppatori. –

+0

Sono l'unico per chi non riesce a spingere su Heroku? (si lamenta di una discrepanza tra Gemfile e Gemfile.lock) – user456584

-1

(fondamentalmente la stessa idea come nel commento di August Lilleaas: gitignore)

Mettere il default/minimal Gemfile in SCM e quindi avere gli sviluppatori cambiano sui loro sistemi e mai commettere. Chiedi loro di aggiungerlo al loro changeset inattivo nel loro client SVN (se ne usano uno), altri SCM dovrebbero avere qualcosa di simile.

Questo è come facciamo questo nella mia azienda - funziona davvero bene :)

+1

A chi ha dato il -1, per favore (sempre) specificare il perché. – sscirrus

+0

Grazie, sscirrus. –

+2

Questo non risolve il problema dei file Gemfile.lock differenziali tra gli sviluppatori (che dovrebbero essere archiviati e OP dice che lo stanno facendo). Gli sviluppatori potrebbero commettere solo alcune modifiche a Gemfile.lock, ma questo è poco pratico. –

2

È possibile utilizzare without bandiera della Bundler di escludere gruppi.

Se avete il seguente Gemfile

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

È possibile escluderli con bundle install

$ bundle install --without jakubs_testing_tools 

http://gembundler.com/groups.html

+0

questo sembrerebbe giusto ma siamo in 5 nella squadra quindi non ha grandi dimensioni - ma è ovviamente fattibile ... ma per quanto riguarda Gemfile.lock - come è interessato? – Jakub

2

E non vi aiuterà in questo momento, ma c'è stato un open feature request per Bundler aggiungere il supporto per un Gemfile.local per anni. È previsto per qualche parte nella serie 1.x, quindi rimanete sintonizzati.

Se il tuo problema principale sono le gemme IRB specifiche dello sviluppatore, ci sono un paio di soluzioni alternative nel numero comments del problema.

+0

[Decisione ufficiale attuale] (https://github.com/bundler/bundler/issues/183#issuecomment-22037131) è che non è supportato. I workaround che colleghi o la risposta principale qui sono buone opzioni –

+0

che fa schifo a causa del problema in cui il tuo Gemfile.lock avrà tutta questa spazzatura in esso. – patrick

Problemi correlati