Prashant and I went away and did some research on including Ruby on Rails in OpenSolaris. We spoke to various people both inside and outside of Sun and came to the same conclusion that many of you did during the initial discussions, that the best option is not to include Ruby on Rails in OpenSolaris. Users wanting to install Ruby on Rails on an OpenSolaris based system would use the now traditional "gem install rails" syntax and all Gems installed on the system would be managed by RubyGems. There would be no alternative repository squirrelled away on the GEM_PATH and there will be no stomping on of files that belong to Solaris packages.
This relies on RubyGems on OpenSolaris being able to handle the vast majority of Gems that there are available today, this includes Pure Ruby gems, gems with native C extensions, gems with native C++ extensions and gems that have a combination of some or all of these. We have an ongoing engineering effort in progress currently to ensure that we have the most robust integration of RubyGems possible and we'll cover that in a separate email. Here are our findings, with the conclusions listed at the bottom. Most of the scenarios have been discussed before at some level on this alias ( see http://opensolaris.org/jive/thread.jspa?threadID=52256) <doc> Scenario 1: Use Solaris packaging exclusively(ie., gems not allowed) -------------- Pros: -> We have control when it comes to native gems. ie., we can precompile gems that would just need to be "laid out" on the file system. Cons: -> The gem format is increasing in popularity. It's now been incorporated into Ruby 1.9. So it seems likely that non gem packagers(like Sun) will begin to face problems in obtaining non gem sources to package into Solaris. -> Some software packages(like Rails) have very frequent release cycles. Even if #1 above was not true, we would find it impossible to update our packages frequently enough, for them to be useful to end users. -> If we package software in a non-gem format, then applications that are coded with "require_gem" will break, even if the required functionality is installed. -> At the moment we are only looking at Rails and it's dependencies. To make this work we would really need to apply this to all Gems or we will move into scenario 2. Scenario 2: Get Solaris and Rails RubyGems to co-exist -------------- 2a. Use a single repository. Pros: -> Single version of the libraries on the system. -> Pkg and gem would be interoperable. Cons: -> gem would stomp on files installed by pkg - thus "corrupting" the packages. This is a major problem during system security audits. It's also completely frowned upon 2b. Multiple repositories. Pros: -> GEM_PATH allows for the latest(or a specific) version of a package to be picked from one of many repositories, so the Sun packages would not be eclipsed if the user installs her own gem. -> This option would work predictably if(and only if) the user used gem or pkg, but not both commands, because invoking each of these command could return different versions of a package. Cons: -> There is no interoperability in this case, so it doesn't really fall into scenario 2. ie., if we use two repositories, gem will have to exclusively administer one, and pkg the other. -> The stomping problem is still not solved, since Rails places files outside the repository, files such as the Rails and Rake executable -> It's not possible to create a sense of hierarchy across two repositories(ie., GEM_PATH=/A:/B doesn't imply that gem X which is available in both these repositories will be loaded only from /A, or for that matter, /B). So, library loading behavior is more complicated. Scenario 3: Gems only -------------- Pros: -> A single Gem repository. No tension between Solaris package and Ruby Gems -> Ruby Gems are the de facto way for most people to install extensions to Ruby. It is familiar to anyone with a reasonable level of expertise and is used in most tutorials and books on Ruby and Ruby on Rails. Ruby Gems are now integrated into Ruby 1.9 -> The Rails gem and it's dependencies are updated frequently. It would be almost impossible to maintain lockstep with the Gem updates. Using Ruby Gems allows for immediate access to updates. Cons: -> On Indiana, running 'pkg install ruby-x.x.x' will install Ruby and Ruby Gems. After performing this step, it might seem logical to run 'pkg install rails-x.x.x' -> gems with native extensions cannot be provided in pre-compiled form. Something that might be useful in some scenarios Scenario 4: Solaris/Indiana package wrapping Ruby Gems -------------- Note: This would not have any "stompable" files as part of the Solaris package manifest. A directory with pre-built Ruby Gems would be created temporarily in /tmp and the "gem" command invoked to install each of the Gems. Pros: -> Community standard gem installer used to install gems via a package mechanism. After installation of the Rails package, Ruby Gems can be used to manage the Gems installed by the package -> A single Gem repository. No tension between Solaris packages and Ruby Gems -> Gems such as mysql and postgres-ruby can be precompiled and therefore can be installed on systems that do not have the compiler installed -> All the Pros of scenario 3 Cons: -> Requires scripting which isn't supported in the Indiana Packaging System -> May have hidden complications around versioning Conclusions ----------------- Scenario 1 is doable but is probably the worst choice that we can make. If we were to decide to do this for all Gems then it might make sense (not going into the difficulties of doing that), but just for Rails it seems extremely short sighted. Scenario 2a is not an option due to the issue with corrupting packages, system security audits could flag this as a false positive of some incursion. Scenario 2b does not completely solve the stomping problem for Rails/deps which 2a has (because of the likes of the Rails and Rake executables). But this option should be explored for other Ruby gems on a case by case basis, in the future. Scenario 3 is the industry standard way of installing Ruby extensions and not only is it easy to use, it's expected that it will be there. Very few people will have a problem with typing "gem install rails" or "sudo gem install rails" to get Rails support. The likelihood is that even if we provide a Solaris/Indiana Rails package, very few people will ever use it. This is the best option but we do have to make sure that the Gem system on Solaris/Indiana is robust though. Scenario 4 would have been a great solution, but scripting is not allowed in Indiana so this option is not possible. </Doc> Prashant and Amanda
