V různých recenzích Fedory 17, zaměřujících se na nové vlastnosti, se téměř ztrácí obrovské množství práce odvedené členy Fedora Ruby SIG. Fedora 17 totiž nejen obsahuje nejnovější stabilní verzi Ruby (1.9.3), ale přináší i celou řadu vylepšení v rámci integrace funkcionality RubyGems do systému. Ale všechno pěkně popořadě.

Ruby 1.9.3

Jak už bylo uvedeno výše, Fedora 17 obsahuje nejnovější stabilní verzi MRI Ruby (MRI = Matz's Ruby Interpreter, originální implementace Ruby). Tato verze obsahuje mnoho vylepšení, ale i jistou míru nekompatibility s Ruby 1.8.7 používaného ve Fedoře 16. I z tohoto důvodu byly všechny balíky ve Fedoře, které na Ruby závisí, upraveny a otestovány. Zajímavostí je, že těchto balíků je zhruba 300, což je obrovské číslo – zejména když vezmeme v potaz, že na celém přechodu se podílelo zhruba 5 lidí.

Balíkářovo peklo, balíkářův ráj

Fedora jako distribuce přísně zakazuje takzvané „bundled libraries“, tj. knihovny, které autoři jiné knihovny beze změn zakomponují do svého zdrojového kódu. Problém nastává, když je v takto zakomponované knihovně nalezena chyba. Pak je třeba opravit všechny výskyty této chyby. To je jednak zbytečně pracné, ale hlavně nebezpečné, protože se lehce stane, že se na nějaký výskyt zapomene. O „bundled libraries“ se zmiňuji proto, že nejnovější verze MRI Ruby jich obsahuje 5 a je povinností balíkáře se s takovou situací vypořádat a zajistit, aby knihovny byly ve Fedoře jen jednou a všechen na nich závisící software je používal správně. Že to není jednoduchá záležitost a působí to různé problémy nejen s infrastrukturou, nám Ruby 1.9.3 už několikrát potvrdilo.

Na druhé straně jsme kvůli zjednodušení balení tzv. „gemů“ (balíkovací systém Ruby implementovaný knihovnou RubyGems) do RPM přidali celou sadu maker, která výrazně zjednodušují tento proces. O balení gemů si povíme v příštím článku.

A proč vlastně balíte gemy?

Mezi vývojáři v Ruby se jako balíkáři často setkáváme s nepochopením. Ptají se nás, proč balit gemy do RPM, stejně je nikdo nebude používat, všichni mají RVM (Ruby Version Manager) a Bundler, všichni používají gem install foo a ne yum install rubygem-foo.

Odpověď je jednoduchá: U gemů zabalených jako RPM dostáváte podporu naší Fedora Ruby SIG. To znamená, že se můžete spolehnout, že po celý život každého vydání Fedory máte jistotu, že stejná verze balíků bude podporovaná a stabilní a budou v ní opraveny bezpečnostní i jiné chyby.

Další výhodou je, že RPM umí pracovat i se závislostmi, které sahají za hranice světa Ruby. Například gem Nokogiri potřebuje pro běh knihovny libxml2 a libxslt, které ale knihovna RubyGems nainstalovat neumí – na rozdíl od RPM. Díky tomu, že je Fedora binární distribuce, nejsou pro instalaci RPM gemů potřeba vývojářské nástroje jako kompilátory atp. (což je nutné u instalace pomocí RubyGems, kde se distribuuje pouze zdrojový kód a případná kompilace binárních rozšíření probíhá až u uživatele).

Ale stejně se na tom vyvíjet nedá

Dá. Jako balíkáři chápeme potřeby vývojářů v Ruby, takže se snažíme nedělat jenom pouhou konverzi gemů na RPM a jejich následnou údržbu, ale i smysluplně integrovat RubyGems s Fedorou. V tomto směru je Fedora 17 velkým pokrokem (a vzdaluje se i ostatním distribucím). Považte sami:

Jedním z problémů RubyGems jako balíkovacího systému ve většině linuxových distribucí bývá míchaní systémových (v našem případě RPM) a nesystémových (nainstalovaných z rubygems.org pomocí příkazu gem install) gemů. Navíc gemy se většinou nachází někde v hierarchii adresáře /usr nebo /var, kam běžní uživatelé nemohou instalovat. Proto Fedora 17 obsahuje tři různé adresáře, ze kterých se gemy nahrávají a do kterých se instalují pomocí různých postupů:

  • Pokud běžný uživatel spustí příkaz gem install foo, nainstaluje se gem foo do jeho adresáře ~/.gem. Je tedy přístupný pouze tomuto uživateli a ostatní uživatelé jej nevidí a neobtěžuje je.
  • Pokud superuživatel spustí příkaz gem install foo, nainstaluje se gem do hierarchie v /usr/local. Takovýto gem je pak viditelný a použitelný pro všechny uživatele.
  • gemy systémové, instalované pomocí RPM (yum install rubygem-foo), mají vyhrazené místo v hierarchii /usr a implicitně jsou příkazem gem nedotknutelné – pracuje se s nimi pouze pomocí RPM, resp. YUM.

Takže co z toho?

Z toho vyplývá, že ideální životní cyklus aplikací Ruby na Fedoře 17 je:

  • Instalace gemů běžným uživatelem a jejich používání při vývoji.
  • Produkční nasazení používající systémové gemy, u kterých je garantovaná podpora a stabilita.

Všechny tyto vlastnosti budete u ostatních distribucí zatím hledat jen těžko. Také míra podpory je u Fedory velmi dobrá a počet systémových gemů je u nás zdaleka nejvyšší ze všech distribucí, takže hurá vyvíjet na Fedoru 🙂

A co dál?

Jako další krok jsme si vytyčili sjednocení knihovny RubyGems pro MRI Ruby a JRuby – v současném stavu mají JRuby a MRI Ruby každé svou vlastní kopii RubyGems (v případě JRuby mírně modifikovanou) a gemy se instalují odděleně. Naším cílem je dosáhnout stavu, kdy se nám podaří sloučit tyto dvě knihovny do jedné univerzální, kterou budou používat obě zmíněné implementace (stejně jako většinu gemů). Tyto problémy již řešíme s vývojáři RubyGems i JRuby, nicméně zatím nemáme přesnou představu, kdy naše úsilí přinese první plody.

Ruby SIG také dále rozebírá přístup k implementaci knihovny Bundler s Fedorou a další možnosti, které by mohly vývojářům v Ruby zpříjemnit používání našeho systému.

Informace o Fedora Ruby SIG

web: https://fedoraproject.org/wiki/Ruby_SIG
mailing list: http://lists.fedoraproject.org/pipermail/ruby-sig/

Jako člen Fedora Ruby SIG bych chtěl tímto poděkovat všem, kteří se aktivně podíleli na přechodu k Ruby 1.9.3. Zejména to jsou Vít Ondrůch, Mamoru Tasaka, Mo Morsi, ale i mnoho dalších.