Fedora 17 a Ruby

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.

Vydáno s licencí Creative Commons BY-SA 3.0.

6 komentářů u “Fedora 17 a Ruby

  1. To by urcite slo, ale osobne mam ted tolik prace, ze nevim kam driv skocit – a tohle by chtelo hodne casu.

  2. A jak je to s prioritami gemů? Co když budu mít jeden a tentýž gem nainstalovaný z repozitářů, zároveň přes roota a ještě uživatelsky. A každý bude v jiné verzi. Který dostane přednost?

    A uživatelsky instalované gemy jsou tedy zcela nezávislé na balíčkovacím systému? Tedy dostanu to samé, co by mi dalo RVM?

    Jestli to chápu dobře, tak když pak budu v Apachi používat suexec a každý virtual host poběží tedy pod vlastním uživatelem, tak se automaticky budou přepínat gemy instalované pod tím uživatelem.

    Ještě jsem Ruby na serveru nikdy nezprovozňoval, pouze na localhostu právě přes RVM, nicméně se na to chystám a kvůli tomuto článku trochu váhám. Původně jsem už byl rozhodnut pro RVM. Ale čím víc o tom přemýšlím…

    • Diky za dotaz, vezmu to poporade:
      - Prioritu muzete zjistit pomoci prikazu „gem env“, pricemz cesty se berou odshora dolu, takze prvne se prochazi gemy uzivatele, potom roota a nakonec systemove. Nicmene obecne pocitame s tim, ze vetsina lidi pouzije bundler, ve kterem specifikuje verzi gemu, takze se pak pouzije ten, ktery je specifikovany v Gemfile[.lock].
      - Ano, gemy instalovane uzivatelem a rootem pomoci „gem install“ jsou zcela nezavisle na systemovych s jednou vyjimkou – momentalne je potreba pouzivat systemovy bundler (# yum install rubygem-bundler).
      - Ano, kazdy uzivatel uvidi gemy, ktere si nainstaloval sam (+ gemy nainstalovane rootem + systemove gemy).
      Jsem rad ze Vas nas pristup zaujal :) Mimochodem zpracoval jsem takovou technictejsi dokumentaci k chovani ruby v anglictine, kdybyste se chtel (nebo kdokoliv jiny) podivat: http://bkabrda.fedorapeople.org/fedora17-ruby-eng-v2.pdf

      • Děkuji za odpovědi, moc mi pomohly si ujasnit, jak to funguje.

        Zatím jsem to zkoušel na localhostu, kde mám RVM. Přepnul jsem to na systémové ruby a zkoušel jsem si, jak se ty gemy chovají a vše fungovalo moc pěkně. Případně i jako plus vidím to, že to může fungovat hned vedle RVM.

        Pro nenáročné projekty by se tedy dalo použít systémové řešení (většina), a bude-li někdy třeba nějaké spešl věci, dá se to zkombinovat s RVM. Rozhodně mi jako mnohem důvěryhodnější přijde řešení z balíčkovací systému, už jen kvůli stabilitě a kompatibilitě.
        Ještě jednou děkuji.

        • Super :)
          Jeste jedno male upresneni: na tom poradi prochazenych cest k gemum vlastne ani nezalezi, protoze pokud se nespecifikuje verze, pak je nahran gem nejvyssi verze, at uz je kdekoliv.

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *

Můžete používat následující HTML značky a atributy: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Nápověda ke komentování

Při psaní komentáře můžete využít HTML značky <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> .