Devo commettere Godeps/_workspace o Godeps.json è sufficiente?

Question

Sto scrivendo un progetto in Go per essere distribuito su heroku, gestendo le dipendenze con godep.

Quando ho godep save, ho sia un file Godeps.json elenca le mie dipendenze con le versioni ed un _workspace/ directory con la fonte di tutte le dipendenze copiati in. Preferirei non commetto _workspace, tutto ciò che il codice è già su GitHub altrove. Sembra che Godeps.json abbia tutte le informazioni necessarie a go get le dipendenze bloccate dalla versione in fase di compilazione di heroku.

Severalsources consiglia di impegnare l'intera directory Godeps/, ma altri lo suggeriscono might not be necessary.

La documentazione godep non sono di grande aiuto:

Questo vi farà risparmiare un elenco di dipendenze al file Godeps/Godeps.json, e copiare il codice sorgente in Godeps/_workspace. Leggi il suo contenuto e assicurati che sia ragionevole. Quindi commettere il il file al controllo della versione.

Is Godeps.json il file?

Answer 1

risposta ufficiale:

Da problema GitHub #131:

L'utilizzo previsto di godep è quello di dipendenze vendor e commettere la directory _workspace al controllo di versione. Vedi il documento della proposta di @kr collegato in # 123 (proposta: http://goo.gl/RpYs8e) Come discusso in quella proposta, godep aveva una modalità (-copy = false) che non supportava la distribuzione delle dipendenze. La mia ipotesi è che il linguaggio ambiguo nel Readme potrebbe essere dovuto a quello. Questa modalità è stata rimossa come documentato in # 123.

Ecco anche godep autore parla del suo progetto e le idee dietro - Vendoring and Import Path Rewriting

Opinione personale:

Non credo ci sia un modo giusto per farlo.

Commettere fornitore librerie sembra imbarazzante, ma ha i suoi vantaggi:

• Non stai basandosi su servizi esterni (GitHub, ecc). GitHub ha interruzioni, forse hai qualche orribile politica aziendale che ti impedisce di usarlo, forse il repository scompare o la sua storia viene riscritta, forse sei dietro firewall (staging/build server), ecc.
• Ogni volta che ci sono aggiornamenti ai tuoi deps ottieni una bella differenza rispetto a cosa è cambiato. Che aiuta quando si aggiorna alla versione più recente, o semplicemente si tiene traccia delle modifiche se si scherma il codice che viene utilizzato.

Alla fine spetta a voi per valutare i pro ei contro. Personalmente rabbrividisco ogni volta che devo commettere codice fornitore, ma nei miei progetti Go lo faccio. Almeno per ora.

Anche aziende come Google e Facebook tengono quasi tutto in un unico repository e questo include il codice fornitore (o così ho sentito).

Interessante articolo sul tema: Go Package Management

Answer 2

Godep avrà bisogno del file json per poter leggere le dipendenze, come mostrato in update.go.
Quindi il file deve essere versionato.

Ma poi godep would fill the content of godep/_workspace, che significa che è un contenuto "generato": non è necessario per la versione.

Answer 3

Basta aggiungere il file Godeps.json al repository e _workspace all'elenco .gitignore :).

Mentre il codice deve essere completamente incluso nel repository, le dipendenze devono essere semplicemente referenziate in qualche modo (godep.json, package.json, git submodule ... si sceglie), e nient'altro. Le stesse tattiche si applicano a npm, bower, apt e tutti gli altri gestori di pacchetti.

Il tuo repository - le tue cose + riferimenti alle librerie dei fornitori (ovviamente, quando è possibile, non puoi fare riferimento al file zip di sourceforge).

Come @VonC ha detto, non vogliamo le librerie dei produttori di versioni.