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>

Comments:

To address some of your concerns about the bin stubs:

`gem install -E` will use /usr/bin/env in its shebang.

You can run with different versions of ruby using the `ruby19 -S stub_file ...` to switch to the other version. Of course, you must have the gem installed for 1.8 and 1.9.

I think for ruby 1.9 I will change RubyGems to install stubs with bin prefix and suffix if a command-line flag is given.

Maybe GEM_HOME and GEM_PATH should be settable in ~/.gemrc too. There was talk of a /etc/gemrc, but I believe it was dropped. Since this type of feature is used by a minority of gem users, it doesn't get much attention.

Posted by Eric Hodel on October 13, 2007 at 11:45 AM PDT #

A big THANK YOU for not trying to shoehorn every gem into its own full-blown Solaris package. That way madness lies :)

Posted by Dick Davies on October 14, 2007 at 02:23 PM PDT #

Eric,

Thank you much for the note. "gem install -E" rocks!

The /etc/gemrc sounded like it would have pretty useful. ButI can look into adding GEM_HOME to ~/.profile or ~/.login as a workaround.

( Will have to locate the right cases to ask for this to be added in.)

For the first release, users will have to set the variable manually.

I need to look into the "ruby19 -S" . . .

Dick,
Thanks for the validation. We, of course, want to be friendly with gems/rubygems.

We'll have to think of a way to also bundle some gems in Solaris(like Rails, Mongrel etc.,) while maintaining Rubygems compatibility.

The first integration into Nevada will have Ruby + Rubygems.

-ps

Posted by Prashant Srinivasan on October 14, 2007 at 05:10 PM PDT #

Post a Comment:
Comments are closed for this entry.
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