2012-02-13 6 views
55

Zauważyłem, że na rubygems.org wiele klejnotów sugeruje, aby określić je w wersji głównej, a nie w dokładnej. Na przykład ...Czy muszę podać dokładne wersje w moim Gemfile?

The haml-rails gem ...

gem "haml-rails", "~> 0.3.4" # "$ bundle install" will acquire the 
           # latest version before 1.0. 

Jednak na podstawie Bundler docs to brzmiało dla mnie jak byłoby lepiej do paznokci w dół dokładnie wersję takiego ...

gem "haml-rails", "0.3.4" 

Więc masz swój klejnot w szynach i wszystkie jego zależności nie będą płynęły do ​​przodu. Jeśli wypróbujesz projekt na innej maszynie kilka tygodni później i uruchomisz $ bundle install, będziesz miał dokładnie te same wersje wszystkiego, co podałeś.

Zauważyłem, że zwolnienia pointów łamią rzeczy, a ja myślałem, że częścią całego pomysłu Bundlera jest "Bundle.lock" wszystkie twoje wersje klejnotów.

Ale na rubygems.org często używają "~>", więc może czegoś brakuje?

Wszelkie wyjaśnienia byłyby bardzo pomocne dla mnie w zrozumieniu zarządzania Bundlerami i klejnotami.

Odpowiedz

51

Jest to celem pliku Gemfile.lock - uruchamianie bundle install z Gemfile.lock obecny tylko instaluje przy użyciu zależności wymienionych tam; nie jest to ponowne rozwiązanie Gemfile. Aby zaktualizować zależności/zaktualizować wersje klejnotów, musisz jawnie wykonać bundle update, który zaktualizuje twój plik Gemfile.lock.

Jeśli nie było pliku Gemfile.lock, wdrożenie kodu do produkcji byłoby poważnym problemem, ponieważ, jak wspomniałeś, zależności i wersje klejnotów mogły się zmienić.

Podsumowując, powinieneś być ogólnie bezpieczny używając operatora ograniczenia wersji pesymistycznej (~>), jak radzi rubygems.org. Pamiętaj o ponownym uruchomieniu testów po wykonaniu bundle update, aby się upewnić, że nic nie zepsuje się.

Jest nice article autorstwa Yehuda Katz, który ma trochę więcej informacji o Gemfile.lock.

+0

OK, więc klejnoty pozostają w ustalonych wersjach nagranych w Gemfile.lock. Jaki jest cel dodawania "~>"? Jak to jest korzystne? – Ethan

+2

@ethan RubyGems wyjaśnia [dokument] (http://rubygems.rubyforge.org/rubygems-update/Gem/Version.html) (patrz sekcja "Zapobieganie katastrofie wersji"). Istotą jest to, że pozwala ona tylko na zwiększenie całkowitej liczby całkowitej w numerze wersji (np. "~> 1.0.5" pozwala na aktualizację do wersji 1.0.9999, ale nigdy do wersji 1.1.x). Mechanizm ten umożliwia aktualizowanie klejnotów, ale bez wprowadzania niezgodności, które mogą powodować błędy (zakłada się, że klejnoty przestrzegają zasad "Rational Versioning", które łączą kontury). –

+1

@ethan Oto kilka dodatkowych linków na stronie RubyDocs na temat "[pesymistycznego operatora] (http://docs.rubygems.org/read/chapter/16#page74)" (~>) i [racjonalnej wersji] (http : //docs.rubygems.org/read/chapter/7). –

5

Zdecydowanie użyłbym dokładnych numerów wersji. Prawdopodobnie możesz po prostu zablokować go do wersji głównej lub nigdy nie określać żadnej wersji i być w porządku, ale jeśli naprawdę chcesz mieć tak drobny poziom kontroli i mieć 100% pewności co do swojego programu, gdy jesteś uruchomiony na innych komputerach, używaj dokładnych numerów wersji.

Byłem w sytuacjach, gdy dokładny numer wersji nie został określony, a kiedy ja lub ktoś inny wykonał bundle install, projekt się zepsuł, ponieważ przeszedł do nowszej wersji. Może to być szczególnie złe podczas wdrażania do produkcji.

Bundler robi blokuje twoje specyfikacje klejnotów, ale jeśli mówisz, żeby używał głównej wersji, to blokuje to w. Tak po prostu wie "O, że wersja jest zablokowana na> 0.1" lub cokolwiek, ale nie "O, wersja jest zamknięta w szczególności pod 0.1.2.3".

+8

Jeśli 'Gemfile.lock' jest obecny, Bundler faktycznie wie, którą konkretną wersję zainstalować (dlatego' Gemfile.lock' powinien być przechowywany w repo obok 'Gemfile'). – mipadi

+1

Wykonanie aktualizacji 'bundle update ' może jednak spowodować aktualizację o wiele więcej niż myślisz, nawet jeśli 'Gemfile.lock' jest obecny i może to być sytuacja niebezpieczna i lepka. – MrDanA

+0

Zgadzam się z zaleceniem samych RubyGems w tej sprawie: po prostu użyj pesymistycznego ograniczenia (~>). Zachęca to całą społeczność do układania semantycznych wersji, co jest dobre, a pomiędzy tym a wbudowanymi funkcjami stabilności Gemfile.lock twoje bazy powinny być więcej niż pokryte. – user456584

Powiązane problemy