today: Installing Ruby on Rails with Ruby Enterprise Edition (assuming a ~arch system):
# echo 'RUBY_TARGETS="ruby18 ree18"' >> /etc/make.conf
# emerge rails
# eselect ruby set rubyee18
next week: World domination with three easy commands. ;p
Just a quick message: I have added Ruby Enterprise Edition to the Portage tree, ready for the adventurous to test ;)
The package is in dev-lang/ruby-enterprise, but you'll need to unmask it first. To install rubygems, you should also unmask the ruby_targets_ree18 USE flag in /etc/portage/profile/use.mask.
The usual disclaimer: The package might still kill little bonsaikittens, so be careful!
Does it work? Does it not? Let us know: #gentoo-ruby on freenode as usual.
Captain's log, Stardate, uuuh, December 6th, eh, point five!
Okay, enough already with the lousy Star Trek reference. When you're a frequenter here on Planet Gentoo, you might have seen Diego talk about Ruby and mysterious new Eclasses. I think he covered the motivation and implementation details of what we call ruby-ng.eclass pretty well, so I'll try to give a little end-user info.
First of all, we, the Gentoo Ruby team are pleased to announce that this aforementioned Eclass was commited to the Portage tree yesterday, and that we made an important step towards to unmasking of Ruby 1.9.
Of course it will take more time to adapt all of our ~300 Packages (don't pin me down on that figure) to that new Eclass, but especially ~arch users should see them coming in gradually.
The best thing about this new Eclass is that we finally have proper dependency structures even when dealing with multiple versions and implementations of Ruby, so you won't end up with mysterious failures in the middle of your emerge -vauDN world. Also, you now can control on a per-package base what Ruby versions you want a package installed for.
To accomplish this, we have introduced a new USE_EXPAND variable called RUBY_TARGETS. You might know this type of variable form APACHE2_MODULES, VIDEO_CARDS, or LINGUAS, they basically contain USE flags, just in their own variable.
By default, we set RUBY_TARGETS to ruby18 which means that your Ruby packages are all installed for Ruby 1.8. Later on, you will also be able to add ruby19 for Ruby 1.9, jruby for JRuby, or ree18 for the Ruby Enterprise Edition. (Please note that we do not recommend using any of these three yet, so install and use them with caution!)
RUBY_TARGETS can be as usual set system-wide in make.conf, or you can set ruby_targets_{target} in package.use for single packages. We recommend setting RUBY_TARGETS system wide.
In the emerge output you will see things like this:
[ebuild U ] dev-ruby/test-unit-2.0.4 [2.0.3] USE="-doc -test%" RUBY_TARGETS="ruby18%* ruby19%* -jruby%" 128 kB
In that example, you would get test-unit installed for Ruby 1.8 and 1.9. It would also work on jruby, but you didn't want that.
So, that's what we were up to, as always, feel free to stop by in #gentoo-ruby on FreeNode and chat with us.
My fellow Rubyists,
No worries, I won't give a uberlengthy speech. ;)
It's just, the speedy, shiny new Ruby 1.9.1 is soon to be released. Actually, it already should have been, but there are some things that need to be fixed, you know how it is…
Anyway, here's how we are looking:
We have ebuilds for Ruby 1.9.1 up to patchlevel 129, they build fine, and we pass all but a few tests. ruby-config is replaced by an eselect module that allows seamless switching of Ruby 1.8 and 1.9 including the gem command. We are now verifying the ebuilds in the tree that already have the "build for ruby 1.9" flag set, if they still work fine.
My personal ETA on when it will hit the tree is $release_time + 6 to 8 weeks. We want to be sure that our infrastructure works with the final release.
You can test-drive the release candidates, they are in the Ruby overlay. Via layman: layman -a ruby.
If you got any feedback, or questions, you can reach the Ruby team via ruby@gentoo.org or IRC.
Some well-known Ruby libraries are now included by upstream. Our beloved RubyGems is on board just as is Rake. For us on Gentoo this means that we no longer have to rely on the auto_gem.rb magic that caused quite some trouble in the past. On the other hand, with too much bundled software being a concern for us, we decided not to include rake, but to offer it – as before – in dev-ruby/rake.
For more information, here are some links:
