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.
Comments:

Not bundling Rails is certainly the right choice if you can only bundle by using a non-RubyGems package manager.

Apple bundled Rails (and a ton of other useful frameworks and libraries) by simply including a bunch of gems pre-installed. That's definitely a good way to go too.

But as you say, as long as RubyGems is installed, it's easy as pie.

Posted by DHH on March 20, 2008 at 07:19 AM PDT #

Hi DHH,
Thanks for the comments. Being ardent Rails enthusiasts, our project started as a Rails inclusion into Solaris project.

As we started working out the details of integration with the OS, it became clear that gems would have to be delivered as packages.(just like any other thing that goes into the OS).

I postulated: If they were to be useful to end users, these packages would need to be interoperable with gems.

After a long discussion -
( There's a whole discussion on this forum -
http://opensolaris.org/jive/thread.jspa?threadID=52256 )

The only two possibilities came down to:

(1) lay out prepackaged gems into a repository that gem would also use - and risk "stomping". ie., solaris packages that had their contents modified by some other program(gem in this case).

Though this doesnt seem like a big deal to the developer in me, folks were quick to point out that it could present problems during security audits.

So, option 2.

(2) to package gems in a different repository than the default gem home. They'll be packaged as(and used by) gems, but updated through pkg(the Indiana package manager).

This(two ways to do the same thing) results in a high degree of confusion, and also makes it difficult for us to maintain latest versions of packages(let alone deliver all gems as pkgs).

So we'd at best have a stale repository and have a higher learning curve, which no one wants to ascend.

Finally, we thought it was best to leave things as they are - clean and simple.

I'm still looking for ways to get this done - and any suggestions are definitely welcome. we're now thinking of deploying gems after the OS gets installed(using gem), and before any one knows that they are not there . . .

Posted by Prashant Srinivasan on March 21, 2008 at 03:19 AM 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