Tuesday Mar 18, 2008

Doing The Right Thing, or Why Rails is not in OpenSolaris


If you haven't been watching the discussion on webstack-discuss@opensolaris.org, the news is that Rails will not be integrated with OpenSolaris or Nevada.
ie., an installation of SXCE/SXDE/Nevada/Indiana will have Ruby installed, but Rails will not be available by default.

The recommended way to install Rails and other gems is by using the gem command - using the famous utterance "gem install rails --include-dependencies".
And that's it.

I think this is the right position for us to take. I think it's quite a brave one, and one that shows that we are truly working as a community now, at least in my corner of the universe.
Think about it . . . with other OSes drawing users away from Ruby's native packaging, in order to "do it their way" - what would the natural response from an operating system vendor be? To say "Let it be, a good solution already exists in Rubygems", or "hey, we want XYZ library delivered through our mechanism, irrespective of what the problems are"?

Rubygems is the chosen package manager for Ruby, and abiding by that decision helps Ruby users on Solaris - and people get that. We got a a lot of comments from our user community, as well as from the good folk at Twitter about Solaris packaging for Ruby gems in general - and nobody at Sun, after having heard the story, ever said, "you know, Debian has it, BSD has it, so we should do it too".

And that's a brave step to take.

Thanks to all the folk that provided comments, please keep them coming, and I'm proud of the folk at Sun, for working sincerely with the community.

Saturday Oct 13, 2007

rubygems for opensolaris

Rubygems seems quite easy to put into OpenSolaris. It is a good candidate for /usr/ruby(with appropriate symbolic links from /usr/bin, of course). The gem repository needs to be outside the /usr hierarchy to allow the repository to be administered by users of sparse root zones. /var/ruby/1.8 looks like a good place for this.

The question of versioning model, compatibility, and how to distinguish a stable version from not, all had extemely pleasing answers for a ardent-compatibility-supporter like yours truly :-) thanks to Eric Hodel.(this is data that I was able to incorporate into my ARC case for Ruby). It also seems that Rubygems will have their own release cycles, independent of being included in the Ruby train.

When Rubygems installs a gem with an executable, for example Mongrel, it ties the runtime to the currently installed Ruby version. ie., It uses "#!/usr/ruby/1.8/bin/ruby". and thus, Mongrel will still invoke Ruby 1.8 even when the end user upgrades to ruby 1.9.(it would be cool if Rubygems used "#!/usr/bin/env ruby" instead of hardcoding . . .)
This makes it impossible to reuse the gem repository across different versions of Ruby installed on the same machine.
So a /var/ruby/x.y/gems directory will ensure that each Ruby version has it's own repository.

Should be easy to write a program to migrate gems between these, given the gem cache directory in Rubygems.

<peeve>
Rubygems tends to complain when when invoked after being configured with the non default gem repository directory. This seems like an RFE to me, since you tell the Rubygems installation program where your repository is, why doesn't it remember?

I know, I know, setting the GEM_HOME variable will solve that. But that takes time. Maybe just a few seconds more, but time that doesn't need to be wasted for this.
</peeve>

About

prashant

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today